- Beta 1
- Feature plugin merge window
- Extend the feature plugin merge window to Friday, or later.
- Tag Beta 1 on Friday, or later.
- Do a scrub of enhancement tickets this week, particularly customizer tickets. 1600 UTC tomorrow (Nov. 6) was suggested.
- Hook recursion, #17817, will be discussed further after beta 1 with the aim of having it ready for early 4.2.
- Pending the final call of @ johnbillion, the full UI for the session manager will come later (and will be moved into a plugin in the plugin repository). @jorbin will work up a patch that adds a “Sign out everywhere else” button along with killing all other sessions on password change and capturing data for a future UI.
Uncertainties, Ambiguities, Do Betters
- Shiny Updates may be punted in whole or in part. The necessary folks are preoccupied.
- The Session Manager UI was debated and will likely change for 4.1.
- “We need guidelines for how we handle feature plugins. It’s been really haphazard, and it has affected our ability to get the features in front of a lot of people.”
- There is skepticism that merge and Beta 1 will happen this week.
- @markjaquith will do a merge request post for Focus on make/core.
- @jorbin will work up a patch that adds a “Sign out everywhere else” button along with killing all other sessions on password change and capturing data for a future UI.
- @nacin will leave feedback on #29395
- @drew will look at #21483
Seems like there’s more than a few Customizer-related enhancements. @celloexpressions: ya’ll have an idea about what could be close and what might need to be punted?
Most of the customizer stuff has been ready for/waiting for commit or further feedback for a while
A couple aren’t quite there, but we want to get in if we can because they enhance Twenty Fifteen
#17817: do_action/apply_filters/etc. recursion on same filter kills underlying call
This is quite likely 4.2-early, but could use eyes-on for unit test coverage and regression testing,
To _briefly_ answer (as well as I can), the three questions in the agenda:
Is there enough unit test coverage?
I don’t know.
Does it break plugins which interact with $wp_filter and $wp_actions directly (eg accessing the nested arrays)?
The patch doesn’t touch $wp_actions. $merged_filters is removed. The $wp_filter array will contain WP_Hook objects instead of nested arrays. Those objects can still be accessed as an array, albeit with some of the quirks that come with the ArrayAccess interface (e.g., you can’t indirectly set elements).
Does it “fix” any existing behavior which could be seen as a regression?
Currently, let’s say you have a callback at priority 10. In that, you set another callback with priority 1. The latter ends up running after the former. This patch would change that. Similarly, if you have something at priority 10 and something at priority 11, but the priority 10 callback end up calling the hook recursively, the priority 11 callback won’t run for the outer loop. This patch would change that.
As this is definitely not 4.1 (sorry @jbrinley! though I know you know that), can we sit on this until after beta is out and then chat more later this month? This is a good briefing of things as it stands, and I hope a few of us can pick it up soon, but there are lots of other things on everyone’s plate at the moment.
yep, sounds good @nacin
@mark: Any update on posting the merge request update on make/core?
Got sidetracked yesterday. Will do that now.
Since it’s such a visual thing, I’m just gonna make a video that shows it off and talks through some of the decisions.
Great. Sounds like the patch is looking pretty good too.
yes, patch is good. May need some more around interactions with the old DFW
Has it been flow tested on mobile lately, to make sure it doesn’t break anything?
New DFW is pretty much disabled on mobile because of the screen size
azaozz: Right, I work on that. Also maybe move the button out.
Yeah, it’s disabled…
@drew + @mark Hope it doesnt break a11y
Don’t think so, but please test. :simple_smile:
A visual record of a mobile flow would demonstrate that it is indeed disabled for mobile.
We addressed keyboard accessibility. But please do advise if we missed something.
It doesn’t change anything for accessibility.
We addressed keyboard accessibility. But please do advise if we missed something.
It doesn’t change anything for accessibility.
For the UI outside of the editor
A feature plugin shouldn’t break mobile or accessibility the moment it lands.
I’m not too worried about mobile with Focus, but we don’t have a good record here and I’d like to improve it.
Ryan, right, DFW v2.0 is not loaded on mobile and on old browsers, IE < 9 (edited)
Someone tell me that with a visual record.
We just need to verify that for sure. Yup.
I learned you can tether an iPhone and record video on its screen, so I’ll try that.
Screenshots would probably be good enough for mobile in this case, but cool.
@mark a11y is not just about keyboard. its also eg. about folks not being able to quickly shift *their* focus (viewing field) to something else. and reading through the ticket doesnt really indicate its an automated or a “click this button to”-feature right now.
The button still needs to be removed I think, but I mentioned before I’ll redo that. :simple_smile:
#30264: Users should have a UI for managing sessions
For #30264 – @johnbillion is supposed to be working up a patch. I’ll check with him and if he needs help, will take over. Otherwise I think the only piece we are waiting on is the API on wordpress.org that @nacin is still working on.
User testing of the feature at WCSF only identified some enhancments we can do to make it more mobile friendly, otherwise it was very well received. Note that it still works fine, but the experience on mobile can be made better (edited)
@jorbin: Were there still UI concerns with the single vs many sessions problem?
I know it is a small feature, but this thing wasn’t really a feature plugin. It’s not in the plugin dir, the slug collides with an existing plugin, and hearing “the experience on mobile can be made better” is a bit aggravating.
Not that I know of, but if there are it seems like something we can iron out in beta
Iron it out before merge.
Otherwise these aren’t feature plugins, they’re blobs of code on github that are merged without criteria.
I’m still kind of tempted to bring it in as a single “Sign out of other sessions” button with no extra UI for 4.1, and continue to play with it for 4.2.
Identifying browsers and locations is no small thing.
I hate that idea. I think it adds a button without any context for people to understand “why”
Context could be added.
The context is the other sessions
- Sign out all other sessions *
Lost your phone? Left yourself logged in on a public computer? Need a way to sign out everywhere except your current browser? This is for you.
[ Sign out all other sessions ]
Was going to point to Slack, yeah.
That’s also not say that you can’t just specify the number of other session without spitting out the fine-grained details.
And the context could additionally be “You are signed into this site in %d other locations.”
Yeah I like that idea
Either way, I agree with @nacin that continuing to flesh out the UI/plugin for a future release might be the smartest way to go. (edited)
I think an actual number is possibly more confusing, because we can’t tell them context, and would consider just showing the Slack-like UI if it’s > 1.
That seems confusing to me. %d doesn’t really help me as nacin is pointing out
ok, so is the decision that we punt?
I’m not advocating punting necessarily, I just saw an opening that would allow us to provide immediate user benefit and try to further improve the overall UX and data we can provide.
+1 to a Slack-like explanation without %d sessions, in 4.1
I think punt is still up to @johnbillion, but as it is now, that would be my recommendation (in terms of the detailed UI)
I’d like to see some user testing sessions on the ux of it to see if / how much it is confusing to normal users.
on the +1 side too. Seems the friendliest, while addressing an immediate need.
Also, I’d suggest: “If you think you were compromised, you should change your password. This will also sign you out everywhere.” (And on password change, I don’t know if we clear out all of their sessions, but we should, since they’re dead at that point.)
If we go that route, we should start capturing the UA string and other data in 4.1 so that we have less “unknowns” displayed
@jorbin: Can you possibly work on a patch for the alternate approach?
As a replacement for %d, something like this, perhaps something like this, so as not to completely terrify them: `<small>You are signed into this site in %d other locations. This could be a different browser on your computer, your phone, or another computer.</small>”
I’m not against capturing more data now.
This is the correct repo, yes? https://github.com/johnbillion/wp-session-manager
Contribute to wp-session-manager development by creating an account on GitHub.
Last updated 23 days ago?
I can work up the alternate patch based on this discussion
@nacin: Or the same browser that had its cookies purged, even.
Not in the plugin repo.
Why are we even talking about it?
name conflict on it
its a feature plugin for 4.1
So let’s give it a different slug.
+lots to getting these things into the repo as early as possible.
Better discoverability for feature plugins would be super-handy.
We need guidelines for how we handle feature plugins. It’s been really haphazard, and it has affected our ability to get the features in front of a lot of people.
@johnbillion will need to make the final call, but it sounds like the decision is: Full UI will come later (and will be moved into a plugin in the plugin repositroy), I will work up a patch that adds a “Sign out everywhere else” button along with killing all other sessions on password change and capturing data for a future UI. Any objections to this plan?
I’ve thought about session-by-session, and I agree that it feels plugin-like to me.
But +1 for an easy “sign me out everywhere else”
@jorbin I think that sounds reasonable. If it’s not where we need it to be by Friday, we can wait.
If a feature plugin effort just results in a well-crafted plugin, that’s not a terrible outcome.
@mark @georgestephanis : we could at least use a standard prefix, to “ensure” slug uniqueness: wpf- or something
Smooth installation and updating of plugins and themes
It’s my understanding the decision was made at WCSF to go with shiny installs and leave shiny updates for later
Correct. Updates can already be done in bulk, while installs cannot.
However, all of the people most familiar with the updates code are tied up right now. Beta 1 is unlikely for what we want.
It’s possible some stuff can be aligned by next week, and that’s up to John if he wants to accept some discrete changes.
@nacin: OK. So are you thinking punt for the whole thing?
Right now, I’m not thinking about it. I may have a better idea come Friday.
FS Credentials Modal
#29820: Smooth installation and updating of plugins and themes
#29395: Site Language: Install translations on the fly
FS credentials is tied into updates/installs more than language.
While it’s nice-to-have for language, if language installs can only happen with ‘direct’, I’m not going to cry.
Can you leave some feedback to that effect on 29395?
Sure. @ocean90 is it already good to land, otherwise?
If we can ignore the FS credentials, yes
#5809: Updating a term in one taxonomy affects the term in every taxonomy
I also created some new tickets and dug up some oldies to reflect next steps in the extended Taxonomy Journey
@boone: Is there a specific report where people can follow progress on that roadmap?
Or just the Taxonomy component?
No. Taxonomy component is best for now.
In the next week I’ll write up a make/core post with some updates and some thoughts about the future
that’ll have links to relevant tickets
some of the stuff that went into this had to do with properly handling DB replication lag and such, just to give you an idea.
Yes, this is the equivalent of us building a rocket to go to McDonalds and then disassembling it while in flight.
Apparently we’re looking pretty good as we approach beta.
It’s looking pretty good
we have one milestoned bug with expanding widgets that we’re still trying to figure out
and there are some template tag and customizer enhancements that’d be nice to have solid
but it’s in good shape
@obenland: did you want to chime in on template tags?
Sure. So there are only very few pieces left after a very productive few days at wcsf
One is #29890 which @helen is looking at
#29890: Make menu descriptions available to be displayed on the front-end
Then we have #29808 with two proposed patches
#29808: Post/paging navigation template tags
https://core.trac.wordpress.org/attachment/ticket/29808/29808.8.diff fixing some some bugs and simplifying bits, as well as changing the screen reader text to an h2 as requested by the a11y team (edited)
And https://core.trac.wordpress.org/attachment/ticket/29808/29808.9.diff which would add parity between post and comment navigation template tags (edited)
Between 29808.9.diff and 29890 we could remove two callbacks from Twenty Fifteen
and have a nice set of theme api improvements in 4.1
#29988 would also be a nice improvement that depends on a few other patches outside of the theme (edited)
#29988: Twenty Fifteen: Use JS/postMessage to update the color scheme instead of triggering a page refresh
For the record, 29988.patch will not land in. We have new tickets for this where some are already fixed. But still needs some work. Or a review by me. (edited)
That’s right. The existing patch on 29988 is a standalone proof of concept.
We had kind of lackluster effort on the Friday bug scrubs the last couple of weeks due to WCSF/summit stuff.
As discussed a little bit ago, I’d like to do an enhancement scrub tomorrow morning-ish to see if we can’t clear out some of those outstanding tickets. Any takers for probably 11:00 am EST tomorrow in here?
I guess 16:00 UTC
Would still love to see feedback on this UI adjustment for default categories: https://core.trac.wordpress.org/ticket/26268 :simple_smile:
#26268: Add UI to Category page to indicate default category
I think @helen had some feedback on 26268 but she had to go. I’m not convinced that’s ready for primetime in terms of flow.
If a core committer has a couple minutes, got a running list of tickets that are ready to be committed here: https://make.wordpress.org/core/2014/11/03/open-update-thread/#comment-20901
#21483 would also benefit from feedback. In addition to UI and code, could use docs help from @drew, has an audio/video issue for @wonderboymusic
#21483: Refactor Customizer Upload, Image, and Background Image controls to leverage the media library/modal
@celloexpressions: OK, I can take a look.