- Beta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 3
- Term splitting will be pulled from 4.1 and considered for inclusion at the beginning of the 4.2 cycle.
- Focus will default to off.
- The particulars of Focus UX User experience will be documented.
- RC1 will be Monday the 1st.
- The final beta will be on the 27th or 28th.
- Focus will roll out to wordpress.com An online implementation of WordPress code that lets you immediately access a new WordPress environment to publish your content. WordPress.com is a private company owned by Automattic that hosts the largest multisite in the world. This is arguably the best place to start blogging if you have never touched WordPress before. https://wordpress.com/ for testing.
- String freeze on Wednesday December 3rd.
- The about page will get attention this weekend in preparation for string freeze.
- @mboynes and @boone will work on a term splitting migration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. guide for plugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party authors.
- @markjaquith and @janneke will document Focus UX.
- @stephdau and @dd32 will roll Focus out to wordpress.com.
- @markjaquith @nacin @kimparsell @helen and others will work on the about page.
Taxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies. Roadmap
Let’s kick off with #30335
#30335: Splitting shared terms on term update breaks backward compatibility when using an old term_id
There was some discussion in this channel last night and today about reverting shared term splitting (again)
The long and short of it is that the proposed workarounds on the ticket Created for both bug reports and feature development on the bug tracker. don’t fix as many plugins as hoped
Why is that?
Two things, really
We (me and mboynes) reviewed the top 100 plugins in the repo
1) many more plugins than I’d expected are affected, in that they store term_ids in the DB somehow. We found 11, and that may not be all of them
2) Of those 11, our proposed fixes only addressed 3 of them
That’s 10% of all plugins that were looked at
the others are doing things like direct comparisons against lists of stored term_ids. There’s no tricks we can perform to help support them.
Given these results, we think the attempts at backward compatibility will hurt more than they’ll help.
Well the attempts at back compat Backward compatibility - a desire to ensure that plugins and themes do not break under new releases - is a driving philosophy of WordPress. While it is a commonly accepted software development practice to break compatibility in major releases, WordPress strives to avoid this at all costs. Any backward incompatible change is carefully considered by the entire core development team and announced, with affected plugins often contacted. It should be noted that external libraries, such as jQuery, do have backward incompatible changes between major releases, which is often going to be a greater concern for developers. will introduce inconsistency, which will hurt more than it helps
“muddies the waters”, I think you said
If it was 95% still working, I might be okay with inconsistency.
which is often worse than a complete crap out
But 27% isn’t good.
Right. That’s what I was hoping for when we started the plugin analysis.
So we think that the best way forward is through developer outreach, which will include more publicity, accompanied with some detailed guides to upgrading. (Basically, an explanation of how the ‘split_shared_term’ hook works.) But we don’t think there’s sufficient time for this to happen for 4.1.
We’ll put shared term splitting back in as soon as we go to 4.2 alpha
So, start education now, and do this with no back compat hacks for 4.2?
Further down the line in 4.3 we can look at splitting all terms on core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. upgrade
Bottom line: when this goes live, stuff _will_ break, so we should just make sure we do well by developers in doing our due diligence to warn them about. There will be plenty who don’t catch on, and there isn’t much we can do about that.
Probably still worth logging the splits though (in 4.2)
I think we should keep the `_split_shared_term()` function in core for anyone who does want to hook it in
For slow plugin updaters.
Yes to logging, and yes to keeping the function in.
We won’t be doing any splitting in 4.2
johnbillion: yes, 4.2. no, 4.1
mark: We’ll include info in the developer docs about how to access the logged data if your plugin needs to perform cleanup
So the code stays, just not run by us?
Correct. There’s one action in default-filters.php which will get pulled out
and we’ll stop calling it in `wp_update_term()`
Does the hook fire? What if a plugin wants to run it and another plugin cares about a term id?
Oh in fact those actions can stay. The code we’ll pull out is in `wp_update_term()`
The hook will fire if the function is run. So plugin authors could start building compatibility today, and it would work.
johnbillion: Yeah, on reflection, the actions should stay.
But if a popular plugin does that, it could cause issues
if a popular plugin decides to split terms on its own, it will cause issue
*accounting for split terms* will not
Should they just do it for testing?
Not actually release code yet that runs the split on 4.1 sites?
I think the thought was that the code would be there for _specific installs_ where the dev decided to run it
I would hide this code until ready – why let plugins create more compat problems?
but yeah, if a public plugin does it, it may bork stuff
My use case was for devs who know what they’re doing and want to split terms on a client site
Maybe we should just pull it for 4.1
Maybe noop it.
Or axe it and provide the code for those who know what they are doing. But warned against public release
I think pull it and drop it in as soon as we go 4.2-alpha. Then the “use at your own risk” flag is pretty clear.
Yeah, in retrospect, pulling it until 4.2-alpha is probably the right move. Good thinking @mark
Okay let’s pull it
Wait, who is going to lead the charge on education?
I’m going to prepare a “migration guide” for developers
I’ll help mboynes
As we get stuff ready, we’ll share it for review, and then figure out where it should live
Okay. And make/core it. We can also reach out directly to popular plugins we know are affected.
Next item is #30337 because @tellyworth said he won’t be around long
#30337: Recommended plugins to replace Popular plugins tab
Not sure if @tellyworth is around actually
He just wanted a bit of feedback. This is a blessed task for 4.1 which is mostly an API An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. change
So if anyone wants to try out the plugin which tellyworth linked in the ticket then go ahead
Moving on, we’re at ~75 open tickets on the 4.1 milestone: https://core.trac.wordpress.org/query?status=!closed&component=!Build%2FTest+Tools&milestone=4.1
Which isn’t *too bad* but I would prefer it a little lower
Anyone who wants to help out either by suggesting that a ticket is punted or suggesting that a ticket goes in, that would be appreciated. I’ll be carving through this list tonight and tomorrow
Also thanks to @ocean90 who has been going through it today
RC1, String Freeze, About Page
Next up, RC1 is scheduled for Monday (we’ll do the final beta either late tonight or tomorrow)
Petya was concerned about string freeze
Is anyone not happy with string freeze happening on Monday? That gives translators ~9 days until release
is there any help text that needs updating?
I just saw some today.
In addition, the About screen needs to be written
Before Monday? Yikes.
Hence why I asked :simple_smile:
If we string freeze next Weds that gives us a week to write the About page and it gives the translators a week before release
a week is short
Mind you we don’t have many new strings in 4.1
57 strings for default, 33 strings for admin (and super admin) and 46 strings for Twenty Fifteen
I can take a look at the Help text. @mark, what screen were you referring to?
yes, I know. But I guess it should not be standard 😉
Who wants to take a pop at writing some nice prose for the About page?
I think we can aim for Monday
WordPress Trac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. [15:39]
#30435: 4.1 About screen
String *freeze* by next Weds sounds good. The only thing which should be done earlier is to set up the new project on translate.wordpress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ so we can start with translations.
Do we need @nacin to do that?
Yeah, I already have send him some patches.
Hi, sorry, traveling, forgot.
Life kind of stops in the US tomorrow, so don’t expect things to happen until Friday, if not done today.
The patch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. is easy, the new project is a bear.
I will try to help him.
Nobody fancies writing or thinking about some screenshots for the About page?
Doesn’t need a whole lot on it
@mark: @nacin: have any time through the holiday weekend to do this?
Needs to be someone with HiDPI capability.
I should be able to carve out time on Sat or Sun.
Not necessarily, we can re-do screenshots
Oh, just to help stub it out and get ideas going?
Alright well let’s move this on
I can do our ritual writing sesh come Sunday.
I’m out Saturday and am otherwise just trying to keep abreast of things.
That would be helpful thanks
we will do it. :simple_smile:
Next up, DFW/focus v2
How are people feeling about DFW being auto-on by default?
I vote no.
as in off by default
There’s been some mixed feedback in #feature-focus over the last week
I vote off by default.
off by default
off by default
It’s our most visible feature to users upgrading from < 4.1
If we turn it off by default it begs the question whether it’s good enough to go in
off by default. i like it, but still only when i ask for it.
DFW is a feature, an optional one
I don’t think it raises that question.
i have friends who want an easy way to disable it
the commercial isn’t the point
Because it’s not a new feature. It’s a more useful version of an existing feature.
maybe give usersa choice to switch to DFE if they first use 4.1?
It replaces the current DFW, which is also off by default. Users are accustomed to having to choose to use it.
The whole thing was my idea, and I’m honestly fine with off by default, and keeping a pointer to call it out.
There were three specific wins, and discoverability was only one of them.
Also fine with off.
The other two being a less jarring transition (nothing moves, it’s the same editor), and easier access to power features (they’re there all the time). Also, “on” is “auto”, which means fewer clicks for the people who want it.
Am I right in thinking that defaulting to “off” will put at ease the people murmuring about globally disabling it on a site?
I actually really like the feature and think we could probably get away with on by default, with an admin pointer
Yeah I think so @mark, but there will still be the pointer
pointer is fine, there’s the advert
I don’t find “off by default but TRY THIS OUT!” being off by the default in the sense of “should we have even done this”
I’m definitely strongly in favor of ON by default, fwiw
is there a shortcut, too?
We could have the old shortcut toggle the auto/off switch
It’s a Zen mode, but it’s still fairly jarring if you don’t expect it. @siobhan said in #feature-focus (and I agree) that you kind of get used to the admin.
Actually just opened #30517 related to that.
WordPress Trac [15:56]
#30517: TinyMCE help still references old DFW
I think it’s better to turn it off by default. I think we’ll annoy more people than we’ll please.
Can we get a “Howdy!” in the admin pointer?
there’s always risk of people thinking they broke something when they see it the first time
play dubstep in the admin pointer for all I care
Yeah, the pointer is enough “in your face” to make anybody just try it :simple_smile:
How has the feedback been outside off the default state?
Siobhan pointed out that the bahviour is different depending on the route which your mouse cursor takes when leaving the screen
Because of the menu protection code?
Up and over the top doesn’t reinstate everything, out via the sides does
I think I felt a bug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. along those lines.
@janneke: are we protecting the top as well?
I noticed it + editor scrolling feel a bit weird when the editor isn’t locked to the bottom, such as for a short post or when you scroll to the end.
Due to visibility: hidden of the meta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. boxes below, in part.
Not much we can do about it, but I wish it felt slightly better.
If I remember right admin bar is separate. Shows/hides separately when you hover over it.
Yeah, that’s what it’s doing.
There was a reason for it. :simple_smile:
We could increase the default height of the editor to somewhat mitigate that
there is no top exit zone.
I wouldn’t mine an increased default height. Again, along the lines of “this is the most important thing on this page”
mark: Which is okay?
We should make sure all UX reasons are documented.
Does this even become a thing when there are multiple editors on a page?
if there’s multiple TinyMCE instances, what happens?
It only works for the ‘content’ editor
If TinyMCE is disabled, what happens?
when title isn’t supported, is it still enabled? That’s a good indication of the CPT not being a pure writing experience.
Not sure, need to test. Maybe, but can just as well require support.
I’d be okay with requiring title support.
I’m just trying to think of permutations to consider.
This isn’t on .com yet which is a problem. Needs to be merged there with a feedback form.
Seems weird tying its availability to a field which doesn’t trigger it
How do we get it there asap?
As Matt said it probably should have been on there for some percentage of users when it was a plugin to test it.
I don’t know the answer to that question.
I’ll talk to my team
We can’t hold core things hostage to Automattic processes outside our control.
Correct but it is a good testing ground
Any other points on DFW then?
Who’s going to tweak the Help text?
Only needs a one-sentence change
I was gonna. But was wondering if we could make the Alt-Shift-W shortcut work too. @janneke?
That’s the old shortcut, right?
Was wondering what W stands for.
@janneke: I’ll re-point the shortcut
“Writing”? Don’t know the history.
@johnbillion: I’ve added some on the agenda post for prosperity (edited)
makepot.php threw me a curve ball today, so I’m going to wrangle it and submit a patch for that too :simple_smile:
@janneke, @azaozz: There is already https://core.trac.wordpress.org/attachment/ticket/30450/30450.patch which includes a shortcut. (edited)
Will this be an auto/off toggle? Or will it turn on and forcibly enter the DFW state?
I think it should be the toggle
So its behaviour matches clicking the button
The toggle forces it too.
So clicking it will cause you to instantly enter the mode?
If it was off before.
(I agree with that behavior.)
Otherwise it seems like nothing happened.
Yes and it does that currently
Yes, clicking it forces it ‘on’.
It’s good feedback in both cases (on enters, off exits)
The shortcut will do the same
I have a question… should a CPT be able to disable the DFW feature?
Related, can it disable editor scrolling?
Yes, together with editor-expand.
And it can?
Both at the same time.
Well, so should it be able to only disable DFW? (edited)
CPT registration is so poorly documented. :disappointed:
No, I think scrolling and DFW are closely coupled both technically and conceptually.
Okay, sounds good.
I think disabling DFW without editor scrolling is OK.
I think disabling editor scrolling but keeping DFW is probably not.
Disabling expand and new DFW is done from a filter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. as well.
How does DFW handle editor scrolling being toggled off?
They totally make sense together. Separately, not so much. Relates to having a large body of content to edit.
Right, DFW is only available when editor scrolling is on.
How does a CPT go about disabling DFW and the editor scrolling then?
@johnbillion: if the CPT has editor support, there is a filter: https://core.trac.wordpress.org/browser/trunk/src/wp-admin/edit-form-advanced.php#L23 (edited)
That should pass in the post type
Yeah I agree
That `wp_editor_expand` filter needs some docs. Also needs some context parameters.
Oh it has a doc.
Does that get parsed? It’s three lines above it. /cc @drew
I’m calling </meeting> by the way – open floor for further discussions