- @boone and @mboynes will make a list of plugins affected by term splitting.
- @johnbillion will tag Beta 2 on Thursday.
- @nacin and @dd32 will investigate breakage with the Beta Tester plugin.
I’m going to kick right off with #30335
#30335: Splitting shared terms on term update breaks backward compatibility when using an old term_id
Summary: we are splitting shared terms when they are updated. But this means that one of the previously shared term_taxonomy_ids will get a new term_id. If anyone has stored that term_id somewhere (like in postmeta), it will no longer fetch the proper item.
mboynes and I have worked out some backward compatibility for passing the old `term_id` to `get_terms()`, `get_term()`, and `WP_Tax_Query`.
nacin’s thought was that this was “too heavy” but he was willing to be convinced.
while this is an edge case bug, it can affect some of the most widely plugins (including but not limited to yoast seo, jetpack, Google XML Sitemaps, ACF, etc.
I personally think it’s a pretty lightweight way to prevent breaking most cases of this sort of thing.
@boone: Is the current implementation changing the Term ID of the currently updated one, or of the term that conflicts with it?
The one that is updated gets a new term_id.
some of those plugins will still have to make updates, but #30335 will significantly mitigate the likelihood of this edge case being encountered
A whole bunch of technical discussion…
Are we OK with punting on this until post beta 2? I’d like to see what else breaks in the wild.
johnbillion’s call, but definitely OK with me
That kind of data is helpful.
Also how catastrophic it is when it breaks.
So when we split a term, we’re abandoning the old term ID entirely?
mboynes: Maybe you and I can talk a bit more about assembling examples of plugins and how they’d be supported (or not) by our fix
I definitely think we should wait before reverting. Better to see what breaks now and know, rather than guessing.
@boone sure thing
nacin: No. The updated term gets a new term ID. All others are kept in place.
Got it, it comes down to knowing old term_id + taxonomy => new term_id
I would suggest that, if you want to wait, do a partial punt
at the very least, let’s store the change in the option
otherwise, that data (the old term id => new term id relationship) is lost
mboynes: so you mean try to protect data during beta?
I’m not against that.
Storing data about split terms is not the worst thing in the world even if we don’t provide backward compatibility. But we can cross that bridge when we come to it.
I’m good with that.
Yeah that’s not a bad idea
I think mboynes just means that if we break a site tomorrow, it’d be nice to be able to “fix” it come beta 3 or whatever.
So people who miss the hook firing.
Can update in a month
My last $0.02 on this for today: I’ll be honest, I will be surprised if this does come up during beta. This is a long-tail issue, but I don’t think that makes it any less significant.
I like the idea of the data being there for a plugin to cleanup later.
mark: or core, if we merge this. (and I suspect we will.)
mboynes: I don’t expect to say “oh, there’s no breakage, let’s not do it.” Rather, I hope to see some particularly esoteric breakage that might make us think about other pieces.
yeah i think having an “out” is important, not nearly as concerned about perfect back compat so much as being able to be rescued.
So the plan of attack then is: 1) Store a record of split terms for the moment. 2) Leave term splitting as-is for beta 2. 3) Post some info about how popular plugins break and whether the proposed fix from @mboynes fixes them
I have a feeling that seeing a handful of popular plugins that would be covered by our proposed fix might help to decide the issue one way or another. So mboynes and I will work on that, and we can talk more next week.
Next up, @stephdau has had to nip out but I just wanted to give a brief update on the plugin directory internationalisation work that he’s doing
Steph has posted a comment on the agenda post with a load of details
It’s just a lot of complicated juggling of overly complex systems. :simple_smile:
Briefly, the plugin directory will get internationalised in time for 4.1 which I think is *ace
must run, @nacin will cover language packs plan
I actually have nothing really to report there. It works, it just needs plugins to be opted in, which will happen over the next 1.5 months.
So the only thing that needs changing in core is a toggle in the plugin browser, so users can toggle between plugins available in the installed locale and all plugins, correct?
Moving on, #30404
WordPress Trac [15:45]
#30404: too close to the left sidebar by using woocommerce theme
It looks like Twenty Fifteen’s sidebar is going to cover up content that is too wide to fit in the main content area and could potentially be a pain point
Thoughts? It may mean having to look again at the scrolling vs. fixed behaviour of the sidebar
I really don’t think this is something the theme can/should reasonably address. Might be able to set some sort of max-width on the main body container, but not really related to the fixed vs. unfixed sidebar
The issue is content getting clipped underneath the sidebar instead of just flowing outside of the content area
Looks like `max-width: 100%` would do it?
probably, if placed on the appropriate container out of the actual content areas
Okay, well let’s see what we can do
Does this encourage plugins devs to consider better CSS practices?
Possibly, but it might also affect things like really wide tables (I’ll test after the meeting unless someone else wants to)
Next up, release schedule
I’ll tag Beta 2 tomorrow evening
I’d like to push RC back one week, unless @nacin or @mark disagree
Also Petya asked about string freeze – we don’t want it happening too late so translators have plenty of time to do their translations.
We don’t need to tie a string freeze to RC. I’ll release strings next week so they can get started. The bulk of the strings will be the about page.
The plan for RC is next Wednesday?
Yeah, pushing that to Dec 1 is OK to me.
Dec 1st it is. That’s still 9 days of RC
I’d aim to get it out at the end of next week.
But acknowledging it’ll slip through the weekend.
Expecting to get 40 tickets closed over the weekend, though, is not something you can ever count on.
Right. I for example will be working but traveling Tue–Sun. Not that I have been much help this release.
Moving on, we’ve had a few small issues reported in the Alpha/beta forum but nothing major
#30339 is the worst, which is a simple fix but didn’t get picked up by our current unit tests
#30339: Infinite loop while checking for post slug uniqueness
Trac tickets reported against trunk since Beta 1 for those interested: https://core.trac.wordpress.org/query?status=!closed&type=defect+(bug)&version=trunk&component=!Build%2FTest+Tools&time=2014-11-14..2014-11-19
Now onto everyone’s favourite new feature, the new DFW mode
What, if any, is the current concensus? cc @mark @janneke
#30356 needs a fix, obviously.
#30356: Focus v2: admin menu slides the wrong way with RTL
I haven’t seen a whole lot of feedback on focus.
it’s kind of tough to search for feedback because it’s tough to describe.
I think we fix that bug and let it ride defaulted on for now
I’ve only seen one forum post about it, nacin.
When we start to toy with a pointer we can think about the default.
WordPress Trac [16:09]
#30356: Focus v2: admin menu slides the wrong way with RTL
Is it on for all post types by default?
As long as it supports title & editor, I imagine?
it’s possible that also requiring the title to be supported will more clearly delineate when the editor is designed to be front and center.
Same as editor scrolling, off for mobile, IE8, when no editor, etc.
Ok let’s fix the RTL and roll with it for another week
Beta Tester Plugin
@kimparsell asked me to mention #30405
WordPress Trac [16:12]
#30405: WordPress Beta Tester Plugin Broken + svn trunk update also fails
odd. cc @dd32 ^
As of today?
Super-odd.. I’m not sure whats happening, but I’ll check it out today
My local installs run the Beta Tester plugin, set to bleeding edge nightlies.
So, we never bumped the version string in version.php, that could be it
I suspect that’ll be it
To update, all I have to do is load a page, and it is auto-updated.
The auto-updates aren’t working for me as of today.
I cannot reproduce the SVN issues.
That ticket has two different but slightly related issues.
Since the reporter also opened an issue on the plugin support itself, can we keep the trac on focused on the `svn up` issue? (edited)
I tried using the Beta Tester plugin this past weekend and it didn’t work
Do we need to put the rev number back into the version string in version.php @dd32 ?
It would be nice to have that and/or the date, if possible.
Yeah, it’s also preventing auto-updates from autoupdating dev sites as 4.1-beta1 (WP) == 4.1-beta1 (API offered version)
I think @dd32 and I broke some things. We’ll take a look.
`svn up` is not broken, so I’m not really sure what to say about that.
That’s all I have for this week’s meeting except to say that Friday’s bug scrub will be a 4.1 scrubtactular and you’re all invited
Where we should review this list too: https://core.trac.wordpress.org/query?status=!closed&type=enhancement&type=task+(blessed)&milestone=4.1&groupdesc=1&group=type