https://make.wordpress.org/core/2014/11/19/agenda-for-november-19th-dev-chat/
https://wordpress.slack.com/archives/core/p1416430816002052
Hits
- 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. 1 released
Misses
None?
Decisions
- Term splitting will remain in beta 2 to generate more feedback. https://core.trac.wordpress.org/ticket/30335, https://core.trac.wordpress.org/ticket/5809
- A record of split terms will be stored during beta to provide rescue fallback for testers, just in case.
- Info about how popular plugins break with term splitting will be posted to make/core Core is the set of software required to run WordPress. The Core Development Team builds WordPress..
- Beta 2 will be tagged on Thursday.
- Release Candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). 1 is pushed to December 1st.
- Focus will remain defaulted to on for Beta 2.
- The weekly bug scrub will happen again on Friday. https://core.trac.wordpress.org/query?status=!closed&type=enhancement&type=task+(blessed)&milestone=4.1&groupdesc=1&group=type
Assignments
- @boone and @mboynes will make a list of plugins affected by term splitting.
- @johnbillion will tag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) Beta 2 on Thursday.
- @nacin and @dd32 will investigate breakage with the Beta Tester 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.
Links Mentioned
https://make.wordpress.org/core/2014/11/18/open-academy-mentorship-progam/
https://core.trac.wordpress.org/ticket/30335
https://core.trac.wordpress.org/ticket/30404
https://core.trac.wordpress.org/ticket/30339
https://core.trac.wordpress.org/query?status=!closed&type=defect+(bug)&version=trunk&component=!Build%2FTest+Tools&time=2014-11-14..2014-11-19
https://core.trac.wordpress.org/ticket/30356
https://core.trac.wordpress.org/ticket/30405
https://core.trac.wordpress.org/query?status=!closed&type=enhancement&type=task+(blessed)&milestone=4.1&groupdesc=1&group=type
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:02]
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
https://core.trac.wordpress.org/ticket/30335
boone [15:03]
Thanks johnbillion
boone [15:04]
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.
boone [15:04]
mboynes and I have worked out some backward compatibility for passing the old `term_id` to `get_terms()`, `get_term()`, and `WP_Tax_Query`.
boone [15:05]
nacin’s thought was that this was “too heavy” but he was willing to be convinced.
mboynes [15:05]
while this is an edge case 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., it can affect some of the most widely plugins (including but not limited to yoast seo, jetpack, Google XML Sitemaps, ACF, etc.
boone [15:05]
I personally think it’s a pretty lightweight way to prevent breaking most cases of this sort of thing.
georgestephanis [15:05]
@boone: Is the current implementation changing the Term ID of the currently updated one, or of the term that conflicts with it?
boone [15:06]
The one that is updated gets a new term_id.
mboynes [15:06]
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…
nacin [15:30]
Are we OK with punting on this until post beta 2? I’d like to see what else breaks in the wild.
boone [15:30]
johnbillion’s call, but definitely OK with me
nacin [15:30]
That kind of data is helpful.
mark [15:31]
Also how catastrophic it is when it breaks.
nacin [15:31]
So when we split a term, we’re abandoning the old term ID entirely?
boone [15:31]
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
ethitter [15:31]
I definitely think we should wait before reverting. Better to see what breaks now and know, rather than guessing.
mboynes [15:31]
@boone sure thing
boone [15:31]
nacin: No. The updated term gets a new term ID. All others are kept in place.
nacin [15:31]
Got it, it comes down to knowing old term_id + taxonomy => new term_id
mboynes [15:31]
I would suggest that, if you want to wait, do a partial punt Contributors sometimes use the verb "punt" when talking about a ticket. This means it is being pushed out to a future release. This typically occurs for lower priority tickets near the end of the release cycle that don't "make the cut." In this is colloquial usage of the word, it means to delay or equivocate. (It also describes a play in American football where a team essentially passes up on an opportunity, hoping to put themselves in a better position later to try again.)
boone [15:32]
nacin: Exactly
mboynes [15:32]
at the very least, let’s store the change in the option
mboynes [15:32]
otherwise, that data (the old term id => new term id relationship) is lost
nacin [15:32]
mboynes: so you mean try to protect data during beta?
mboynes [15:32]
yes
nacin [15:33]
I’m not against that.
boone [15:33]
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.
mark [15:34]
I’m good with that.
johnbillion [15:34]
Yeah that’s not a bad idea
nacin [15:34]
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.
mark [15:34]
So people who miss the hook firing.
mark [15:34]
Can update in a month
mboynes [15:34]
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.
mark [15:35]
I like the idea of the data being there for a plugin to cleanup later.
nacin [15:35]
mark: or core, if we merge this. (and I suspect we will.)
nacin [15:35]
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.
helen [15:35]
yeah i think having an “out” is important, not nearly as concerned about perfect 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. so much as being able to be rescued.
johnbillion [15:35]
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
boone [15:35]
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.
Plugin i18n Internationalization, or the act of writing and preparing code to be fully translatable into other languages. Also see localization. Often written with a lowercase i so it is not confused with a lowercase L or the numeral 1. Often an acquired skill.
johnbillion [15:39]
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
johnbillion [15:39]
Steph has posted a comment on the agenda post with a load of details
nacin [15:40]
It’s just a lot of complicated juggling of overly complex systems. :simple_smile:
johnbillion [15:40]
Briefly, the plugin directory will get internationalised in time for 4.1 which I think is *ace
stephdau [15:42]
must run, @nacin will cover language packs plan
nacin [15:43]
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.
johnbillion [15:44]
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 A locale is a combination of language and regional dialect. Usually locales correspond to countries, as is the case with Portuguese (Portugal) and Portuguese (Brazil). Other examples of locales include Canadian English and U.S. English. and all plugins, correct?
nacin [15:44]
Yep.
Twenty Fifteen
johnbillion [15:45]
:thumbsup:
johnbillion [15:45]
Moving on, #30404
WordPress Trac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. [15:45]
#30404: too close to the left sidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. by using woocommerce theme
https://core.trac.wordpress.org/ticket/30404
johnbillion [15:46]
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
adamsilverstein [15:47]
is lurking
johnbillion [15:48]
Thoughts? It may mean having to look again at the scrolling vs. fixed behaviour of the sidebar
celloexpressions [15:49]
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
johnbillion [15:50]
The issue is content getting clipped underneath the sidebar instead of just flowing outside of the content area
azaozz [15:51]
Looks like `max-width: 100%` would do it?
celloexpressions [15:51]
probably, if placed on the appropriate container out of the actual content areas
johnbillion [15:53]
Okay, well let’s see what we can do
deltafactory [15:53]
Does this encourage plugins devs to consider better CSS Cascading Style Sheets. practices?
johnbillion [15:54]
Possibly, but it might also affect things like really wide tables (I’ll test after the meeting unless someone else wants to)
Release Schedule
johnbillion [15:54]
Next up, release schedule
johnbillion [15:55]
I’ll tag Beta 2 tomorrow evening
johnbillion [15:55]
I’d like to push RC One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). back one week, unless @nacin or @mark disagree
johnbillion [15:56]
Also Petya asked about string freeze – we don’t want it happening too late so translators have plenty of time to do their translations.
nacin [15:56]
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.
nacin [15:57]
The plan for RC is next Wednesday?
nacin [15:57]
Next Monday.
nacin [15:57]
Yeah, pushing that to Dec 1 is OK to me.
johnbillion [15:58]
Dec 1st it is. That’s still 9 days of RC
nacin [15:58]
I’d aim to get it out at the end of next week.
nacin [15:59]
But acknowledging it’ll slip through the weekend.
nacin [15:59]
Expecting to get 40 tickets closed over the weekend, though, is not something you can ever count on.
johnbillion [15:59]
Also, Thanksgiving
nacin [16:00]
Right. I for example will be working but traveling Tue–Sun. Not that I have been much help this release.
Beta Feedback
johnbillion [16:00]
Moving on, we’ve had a few small issues reported in the Alpha/beta forum but nothing major
johnbillion [16:01]
#30339 is the worst, which is a simple fix but didn’t get picked up by our current unit tests
#30339: Infinite loop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop. while checking for post slug uniqueness
https://core.trac.wordpress.org/ticket/30339
johnbillion [16:02]
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
Focus
johnbillion [16:03]
Now onto everyone’s favourite new feature, the new DFW mode
johnbillion [16:03]
What, if any, is the current concensus? cc @mark @janneke
mark [16:04]
#30356 needs a fix, obviously.
#30356: Focus v2: admin (and super admin) menu slides the wrong way with RTL
https://core.trac.wordpress.org/ticket/30356
nacin [16:06]
I haven’t seen a whole lot of feedback on focus.
nacin [16:06]
it’s kind of tough to search for feedback because it’s tough to describe.
mark [16:06]
Same.
mark [16:08]
I think we fix that bug and let it ride defaulted on for now
ipstenu [16:09]
I’ve only seen one forum post about it, nacin.
nacin [16:09]
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
nacin [16:10]
Is it on for all post types by default?
nacin [16:10]
As long as it supports title & editor, I imagine?
johnbillion [16:10]
Just editor
nacin [16:11]
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.
azaozz [16:11]
Same as editor scrolling, off for mobile, IE8, when no editor, etc.
johnbillion [16:12]
Ok let’s fix the RTL and roll with it for another week
mark [16:12]
Cool
Beta Tester Plugin
johnbillion [16:12]
@kimparsell asked me to mention #30405
WordPress Trac [16:12]
#30405: WordPress Beta Tester Plugin Broken + svn trunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. update also fails
https://core.trac.wordpress.org/ticket/30405
nacin [16:13]
odd. cc @dd32 ^
nacin [16:13]
As of today?
kimparsell [16:13]
Yes
dd32 [16:13]
Super-odd.. I’m not sure whats happening, but I’ll check it out today
kimparsell [16:13]
My local installs run the Beta Tester plugin, set to bleeding edge The latest revision of the software, generally in development and often unstable. Also known as trunk. nightlies.
nacin [16:14]
So, we never bumped the version string in version.php, that could be it
dd32 [16:14]
I suspect that’ll be it
kimparsell [16:14]
To update, all I have to do is load a page, and it is auto-updated.
kimparsell [16:14]
The auto-updates aren’t working for me as of today.
kimparsell [16:14]
I cannot reproduce the SVN Subversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase. issues.
morganestes [16:15]
That ticket Created for both bug reports and feature development on the bug tracker. has two different but slightly related issues.
morganestes [16:15]
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)
honeysilvas [16:16]
I tried using the Beta Tester plugin this past weekend and it didn’t work
johnbillion [16:16]
Do we need to put the rev number back into the version string in version.php @dd32 ?
kimparsell [16:16]
It would be nice to have that and/or the date, if possible.
kanedahanso [16:17]
joined #core
dd32 [16:17]
Yeah, it’s also preventing auto-updates from autoupdating dev sites as 4.1-beta1 (WP) == 4.1-beta1 (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. offered version)
nacin [16:17]
I think @dd32 and I broke some things. We’ll take a look.
nacin [16:17]
`svn up` is not broken, so I’m not really sure what to say about that.
Bug Scrub
johnbillion [16:18]
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
ocean90 [16:19]
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
