https://wordpress.slack.com/archives/core/p1417035664004117
https://make.wordpress.org/core/2014/11/26/agenda-for-november-26th-dev-chat/
Misses
- 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
Hits
Decisions
- 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.
Assignments
- @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.
Links Mentioned
https://make.wordpress.org/core/2014/11/26/agenda-for-november-26th-dev-chat/
https://core.trac.wordpress.org/ticket/30335
https://core.trac.wordpress.org/ticket/30337
https://core.trac.wordpress.org/ticket/30445
https://core.trac.wordpress.org/query?status=!closed&component=!Build%2FTest+Tools&milestone=4.1
https://core.trac.wordpress.org/ticket/30435
https://core.trac.wordpress.org/ticket/30517
https://core.trac.wordpress.org/browser/trunk/src/wp-admin/edit-form-advanced.php#L23
https://core.trac.wordpress.org/attachment/ticket/30450/30450.patch
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
johnbillion [15:03]
Let’s kick off with #30335
#30335: Splitting shared terms on term update breaks backward compatibility when using an old term_id
https://core.trac.wordpress.org/ticket/30335
johnbillion [15:04]
There was some discussion in this channel last night and today about reverting shared term splitting (again)
johnbillion [15:04]
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
mark [15:04]
Why is that?
boone [15:04]
Two things, really
boone [15:05]
We (me and mboynes) reviewed the top 100 plugins in the repo
boone [15:05]
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
boone [15:05]
2) Of those 11, our proposed fixes only addressed 3 of them
johnbillion [15:06]
That’s 10% of all plugins that were looked at
boone [15:06]
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.
boone [15:06]
Given these results, we think the attempts at backward compatibility will hurt more than they’ll help.
johnbillion [15:07]
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
boone [15:07]
Exactly.
boone [15:07]
“muddies the waters”, I think you said
johnbillion [15:07]
Yeah
mark [15:07]
If it was 95% still working, I might be okay with inconsistency.
stephdau [15:07]
which is often worse than a complete crap out
mark [15:07]
But 27% isn’t good.
boone [15:07]
Right. That’s what I was hoping for when we started the plugin analysis.
boone [15:08]
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.
johnbillion [15:10]
We’ll put shared term splitting back in as soon as we go to 4.2 alpha
mark [15:10]
So, start education now, and do this with no back compat hacks for 4.2?
boone [15:10]
Right.
johnbillion [15:10]
Yep
johnbillion [15:11]
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
mboynes [15:11]
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.
mark [15:12]
Probably still worth logging the splits though (in 4.2)
johnbillion [15:12]
I think we should keep the `_split_shared_term()` function in core for anyone who does want to hook it in
mark [15:12]
For slow plugin updaters.
boone [15:12]
Yes to logging, and yes to keeping the function in.
johnbillion [15:12]
We won’t be doing any splitting in 4.2
mboynes [15:12]
absolutely agree
boone [15:13]
johnbillion: yes, 4.2. no, 4.1
johnbillion [15:13]
Oops sorry
boone [15:14]
mark: We’ll include info in the developer docs about how to access the logged data if your plugin needs to perform cleanup
mark [15:14]
So the code stays, just not run by us?
janneke [15:14]
(hi)
johnbillion [15:14]
Correct. There’s one action in default-filters.php which will get pulled out
boone [15:14]
two :simple_smile:
boone [15:14]
and we’ll stop calling it in `wp_update_term()`
mark [15:14]
Does the hook fire? What if a plugin wants to run it and another plugin cares about a term id?
johnbillion [15:15]
Oh in fact those actions can stay. The code we’ll pull out is in `wp_update_term()`
boone [15:15]
The hook will fire if the function is run. So plugin authors could start building compatibility today, and it would work.
boone [15:15]
johnbillion: Yeah, on reflection, the actions should stay.
mark [15:15]
But if a popular plugin does that, it could cause issues
boone [15:15]
if a popular plugin decides to split terms on its own, it will cause issue
boone [15:16]
*accounting for split terms* will not
mark [15:16]
Should they just do it for testing?
boone [15:16]
hm
mark [15:16]
Not actually release code yet that runs the split on 4.1 sites?
boone [15:16]
I think the thought was that the code would be there for _specific installs_ where the dev decided to run it
wonderboymusic [15:16]
I would hide this code until ready – why let plugins create more compat problems?
boone [15:17]
but yeah, if a public plugin does it, it may bork stuff
johnbillion [15:17]
My use case was for devs who know what they’re doing and want to split terms on a client site
johnbillion [15:17]
Maybe we should just pull it for 4.1
mark [15:17]
Maybe noop it.
mark [15:17]
Or axe it and provide the code for those who know what they are doing. But warned against public release
boone [15:18]
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.
mboynes [15:19]
Yeah, in retrospect, pulling it until 4.2-alpha is probably the right move. Good thinking @mark
johnbillion [15:20]
Okay let’s pull it
mark [15:20]
Wait, who is going to lead the charge on education?
mboynes [15:21]
I’m going to prepare a “migration guide” for developers
boone [15:21]
I’ll help mboynes
boone [15:21]
As we get stuff ready, we’ll share it for review, and then figure out where it should live
mark [15:21]
Okay. And make/core it. We can also reach out directly to popular plugins we know are affected.
Popular Plugins
johnbillion [15:20]
Next item is #30337 because @tellyworth said he won’t be around long
#30337: Recommended plugins to replace Popular plugins tab
https://core.trac.wordpress.org/ticket/30337
johnbillion [15:22]
Not sure if @tellyworth is around actually
johnbillion [15:23]
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
johnbillion [15:23]
So if anyone wants to try out the plugin which tellyworth linked in the ticket then go ahead
4.1 Milestone
johnbillion [15:26]
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
johnbillion [15:26]
Which isn’t *too bad* but I would prefer it a little lower
johnbillion [15:27]
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
johnbillion [15:28]
Also thanks to @ocean90 who has been going through it today
RC1, String Freeze, About Page
johnbillion [15:32]
Next up, RC1 is scheduled for Monday (we’ll do the final beta either late tonight or tomorrow)
johnbillion [15:33]
Petya was concerned about string freeze
johnbillion [15:33]
Is anyone not happy with string freeze happening on Monday? That gives translators ~9 days until release
helen [15:33]
is there any help text that needs updating?
mark [15:34]
I just saw some today.
johnbillion [15:34]
In addition, the About screen needs to be written
mark [15:34]
Before Monday? Yikes.
johnbillion [15:34]
Hence why I asked :simple_smile:
johnbillion [15:35]
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
lumberhack [15:36]
joined #core
coachbirgit [15:36]
a week is short
johnbillion [15:37]
Mind you we don’t have many new strings in 4.1
ocean90 [15:37]
57 strings for default, 33 strings for admin (and super admin) and 46 strings for Twenty Fifteen
kimparsell [15:38]
I can take a look at the Help text. @mark, what screen were you referring to?
coachbirgit [15:38]
yes, I know. But I guess it should not be standard 😉
johnbillion [15:39]
Who wants to take a pop at writing some nice prose for the About page?
johnbillion [15:39]
I think we can aim for Monday
johnbillion [15:39]
#30435
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
https://core.trac.wordpress.org/ticket/30435
ocean90 [15:40]
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.
johnbillion [15:41]
Do we need @nacin to do that?
ocean90 [15:41]
Yeah, I already have send him some patches.
nacin [15:42]
Hi, sorry, traveling, forgot.
mark [15:42]
Life kind of stops in the US tomorrow, so don’t expect things to happen until Friday, if not done today.
nacin [15:42]
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.
ocean90 [15:44]
I will try to help him.
johnbillion [15:44]
Nobody fancies writing or thinking about some screenshots for the About page?
johnbillion [15:44]
Doesn’t need a whole lot on it
helen [15:44]
@mark: @nacin: have any time through the holiday weekend to do this?
mark [15:44]
Needs to be someone with HiDPI capability.
mark [15:44]
I should be able to carve out time on Sat or Sun.
johnbillion [15:45]
Not necessarily, we can re-do screenshots
mark [15:45]
Oh, just to help stub it out and get ideas going?
johnbillion [15:45]
Yep
johnbillion [15:46]
Alright well let’s move this on
nacin [15:46]
I can do our ritual writing sesh come Sunday.
nacin [15:47]
I’m out Saturday and am otherwise just trying to keep abreast of things.
johnbillion [15:47]
That would be helpful thanks
helen [15:47]
we will do it. :simple_smile:
Focus
johnbillion [15:48]
Next up, DFW/focus v2
johnbillion [15:49]
How are people feeling about DFW being auto-on by default?
voldemortensen [15:49]
I vote no.
voldemortensen [15:49]
as in off by default
johnbillion [15:49]
There’s been some mixed feedback in #feature-focus over the last week
kimparsell [15:49]
I vote off by default.
coachbirgit [15:49]
off by default
eric [15:50]
off by default
johnbillion [15:50]
It’s our most visible feature to users upgrading from < 4.1
johnbillion [15:50]
If we turn it off by default it begs the question whether it’s good enough to go in
helen [15:50]
off by default. i like it, but still only when i ask for it.
wonderboymusic [15:50]
DFW is a feature, an optional one
mark [15:50]
I don’t think it raises that question.
tw2113 [15:50]
i have friends who want an easy way to disable it
wonderboymusic [15:51]
the commercial isn’t the point
mark [15:51]
Because it’s not a new feature. It’s a more useful version of an existing feature.
azaozz [15:51]
Right ^^
latz [15:51]
maybe give usersa choice to switch to DFE if they first use 4.1?
kimparsell [15:51]
It replaces the current DFW, which is also off by default. Users are accustomed to having to choose to use it.
mark [15:51]
The whole thing was my idea, and I’m honestly fine with off by default, and keeping a pointer to call it out.
mark [15:52]
There were three specific wins, and discoverability was only one of them.
janneke [15:52]
Also fine with off.
mark [15:53]
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.
mark [15:54]
Am I right in thinking that defaulting to “off” will put at ease the people murmuring about globally disabling it on a site?
johnbillion [15:54]
I actually really like the feature and think we could probably get away with on by default, with an admin pointer
johnbillion [15:54]
Yeah I think so @mark, but there will still be the pointer
wonderboymusic [15:55]
pointer is fine, there’s the advert
nacin [15:55]
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”
celloexpressions [15:55]
I’m definitely strongly in favor of ON by default, fwiw
coachbirgit [15:55]
is there a shortcut, too?
mark [15:56]
We could have the old shortcut toggle the auto/off switch
nacin [15:56]
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.
mark [15:56]
Actually just opened #30517 related to that.
WordPress Trac [15:56]
#30517: TinyMCE help still references old DFW
https://core.trac.wordpress.org/ticket/30517
janneke [15:56]
I think it’s better to turn it off by default. I think we’ll annoy more people than we’ll please.
johnbillion [15:57]
Can we get a “Howdy!” in the admin pointer?
tw2113 [15:57]
there’s always risk of people thinking they broke something when they see it the first time
wonderboymusic [15:57]
play dubstep in the admin pointer for all I care
azaozz [15:57]
Yeah, the pointer is enough “in your face” to make anybody just try it :simple_smile:
nacin [15:57]
How has the feedback been outside off the default state?
johnbillion [15:58]
Siobhan pointed out that the bahviour is different depending on the route which your mouse cursor takes when leaving the screen
mark [15:58]
Because of the menu protection code?
johnbillion [15:58]
Up and over the top doesn’t reinstate everything, out via the sides does
nacin [15:58]
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.
mark [15:59]
@janneke: are we protecting the top as well?
nacin [15:59]
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.
nacin [15:59]
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.
nacin [15:59]
Not much we can do about it, but I wish it felt slightly better.
janneke [16:00]
If I remember right admin bar is separate. Shows/hides separately when you hover over it.
mark [16:00]
Yeah, that’s what it’s doing.
janneke [16:00]
There was a reason for it. :simple_smile:
johnbillion [16:00]
We could increase the default height of the editor to somewhat mitigate that
mark [16:00]
there is no top exit zone.
mark [16:00]
I wouldn’t mine an increased default height. Again, along the lines of “this is the most important thing on this page”
janneke [16:00]
mark: Which is okay?
nacin [16:01]
We should make sure all UX reasons are documented.
mark [16:01]
Agreed. Where?
nacin [16:01]
Does this even become a thing when there are multiple editors on a page?
janneke [16:01]
A thing?
nacin [16:02]
if there’s multiple TinyMCE instances, what happens?
azaozz [16:02]
It only works for the ‘content’ editor
nacin [16:02]
If TinyMCE is disabled, what happens?
nacin [16:02]
when title isn’t supported, is it still enabled? That’s a good indication of the CPT not being a pure writing experience.
janneke [16:03]
Not sure, need to test. Maybe, but can just as well require support.
mark [16:04]
I’d be okay with requiring title support.
nacin [16:04]
I’m just trying to think of permutations to consider.
nacin [16:04]
This isn’t on .com yet which is a problem. Needs to be merged there with a feedback form.
johnbillion [16:04]
Seems weird tying its availability to a field which doesn’t trigger it
janneke [16:05]
How do we get it there asap?
nacin [16:05]
As Matt said it probably should have been on there for some percentage of users when it was a plugin to test it.
nacin [16:05]
I don’t know the answer to that question.
stephdau [16:06]
I’ll talk to my team
stephdau [16:06]
(timezones)
mark [16:06]
We can’t hold core things hostage to Automattic processes outside our control.
stephdau [16:06]
^^ this
johnbillion [16:06]
Correct but it is a good testing ground
johnbillion [16:08]
Any other points on DFW then?
johnbillion [16:08]
Who’s going to tweak the Help text?
johnbillion [16:09]
Only needs a one-sentence change
mark [16:09]
I was gonna. But was wondering if we could make the Alt-Shift-W shortcut work too. @janneke?
janneke [16:09]
Sure.
janneke [16:10]
That’s the old shortcut, right?
mark [16:10]
Yes.
janneke [16:11]
Was wondering what W stands for.
azaozz [16:11]
@janneke: I’ll re-point the shortcut
janneke [16:11]
“Write.”
mark [16:11]
“Writing”? Don’t know the history.
stephdau [16:11]
@johnbillion: I’ve added some on the agenda post for prosperity (edited)
stephdau [16:12]
makepot.php threw me a curve ball today, so I’m going to wrangle it and submit a patch for that too :simple_smile:
ocean90 [16:12]
@janneke, @azaozz: There is already https://core.trac.wordpress.org/attachment/ticket/30450/30450.patch which includes a shortcut. (edited)
janneke [16:13]
That’s f.
mark [16:13]
Will this be an auto/off toggle? Or will it turn on and forcibly enter the DFW state?
johnbillion [16:14]
I think it should be the toggle
johnbillion [16:14]
So its behaviour matches clicking the button
janneke [16:14]
The toggle forces it too.
johnbillion [16:14]
Yeah
mark [16:14]
Okay.
eugene [16:14]
left #core
nacin [16:15]
So clicking it will cause you to instantly enter the mode?
mark [16:15]
If it was off before.
nacin [16:15]
(I agree with that behavior.)
mark [16:15]
Otherwise it seems like nothing happened.
johnbillion [16:15]
Yes and it does that currently
azaozz [16:15]
Yes, clicking it forces it ‘on’.
mark [16:15]
It’s good feedback in both cases (on enters, off exits)
azaozz [16:15]
The shortcut will do the same
mark [16:16]
Okay.
mark [16:17]
I have a question… should a CPT be able to disable the DFW feature?
mark [16:17]
Related, can it disable editor scrolling?
azaozz [16:17]
Yes, together with editor-expand.
azaozz [16:17]
:simple_smile:
mark [16:17]
And it can?
azaozz [16:17]
Both at the same time.
janneke [16:18]
Well, so should it be able to only disable DFW? (edited)
mark [16:18]
CPT registration is so poorly documented. :disappointed:
mark [16:18]
No, I think scrolling and DFW are closely coupled both technically and conceptually.
janneke [16:18]
Okay, sounds good.
nacin [16:18]
I think disabling DFW without editor scrolling is OK.
nacin [16:19]
I think disabling editor scrolling but keeping DFW is probably not.
azaozz [16:19]
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.
nacin [16:19]
How does DFW handle editor scrolling being toggled off?
janneke [16:19]
Doesn’t work.
mark [16:19]
Dependency.
janneke [16:19]
Right.
mark [16:20]
They totally make sense together. Separately, not so much. Relates to having a large body of content to edit.
azaozz [16:20]
Right, DFW is only available when editor scrolling is on.
johnbillion [16:22]
How does a CPT go about disabling DFW and the editor scrolling then?
azaozz [16:24]
@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)
mark [16:25]
That should pass in the post type
johnbillion [16:26]
Yeah I agree
johnbillion [16:27]
That `wp_editor_expand` filter needs some docs. Also needs some context parameters.
johnbillion [16:27]
Oh it has a doc.
johnbillion [16:28]
Does that get parsed? It’s three lines above it. /cc @drew
johnbillion [16:28]
I’m calling </meeting> by the way – open floor for further discussions
