Open Update Thread, Week of December 8th

What’s happening?

#open-update-thread

Dev Chat Summary, December 3rd

https://wordpress.slack.com/archives/core/p1417640435005108

Hits

  • Focus rolled out to wordpress.comWordPress.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/.

Misses

  • BetaBeta 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
  • RC1

Decisions

  • Recommended plugins will move to a new tab in the pluginPlugin 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 installer. The popular plugins tab will remain.
  • Strings will be released to translators on Wed. the 3rd.
  • RC1 possibly on the 3rd. Possibly not.

Assignments

  • @tellyworth will move recommended plugins to a new tab.
  • @johnbillion will work on about page text, clearing the 4.1 milestone, and triaging tickets reported against trunktrunk 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..
  • @nacin will release strings.
  • @johnbillion will tagtag 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.) RC1.

Links Mentioned

https://core.trac.wordpress.org/ticket/30516
https://core.trac.wordpress.org/ticket/30337
https://core.trac.wordpress.org/ticket/30435

Continue reading

New Template Tags in 4.1

Working on a new default theme is always an opportunity to improve coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.’s Theme APIs too. With the release of Twenty Fifteen there are quite a few improvements that made it in:

Archive Template Tags

Theme authors get to use four new functions to use in their archive templates:

  • get_the_archive_title() and the_archive_title() for returning/displaying the title of the current term, date, post type, post format, or author archive.
  • get_the_archive_description() and the_archive_description() for returning/displaying the description associated with the current term archive.

They are especially handy when a theme doesn’t have dedicated templates for taxonomyTaxonomy 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. or date archives, but can essentially be used in all archive templates. The description functions only display term descriptions, since no other archive type really offers descriptions.

Worked on in #21995 and then introduced in r30223.

Navigation Template Tags

Core has provided template tags for links between posts and pages of posts for a long time. Now theme authors can resort to higher-level template tags to display an entire navigation snippet. If you’ve built your themes off of recent default themes, or created child themes from them, these should look very familiar. As a heads up: Since default themes have been developed in HTML5 for five years now, there is no HTML4 version of these tags.

  • get_the_post_navigation() and the_post_navigation() for navigation to the next and previous post.
  • get_the_posts_navigation() and the_posts_navigation() for navigation to the next and previous page of posts.
  • get_the_posts_pagination() and the_posts_pagination() for paginated navigation between pages of posts. (Updated for 4.1 RC1, see this post)

All functions use the same wrapping markup with semantic class names, so it’s easy to style them in one go. The navigation functions accept custom link texts and screen-reader-texts, in case the defaults are not applicable. The pagination functions even accept all arguments that paginate_links() does, too! (Except for the 'type' argument, we need that to be plain so the template tagtag 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.) doesn’t break 😉 )

Worked on in #29808, introduced in r30065, improved in r30457.

Also in 4.1:

Theme Support for Title Tags

I’ve written about title tags before and will refer to that post for more information about the groundbreaking changes that happened here.

Page Template Body Classes

They got a minor update that simplifies those class names and allows theme authors to target folders of page templates. With this /page-templates/full-width.php will produce page-templatepage-template-page-templates, page-template-full-width and page-template-page-templatesfull-width-php. Worked on in #23470 and then introduced in r30100.

#4-1, #bundled-theme, #dev-notes, #themes, #twentyfifteen

Open Update Thread, Week of December 1st

Let it out in the OUT.

#open-update-thread

Dev Chat Summary, November 26th

https://wordpress.slack.com/archives/core/p1417035664004117

https://make.wordpress.org/core/2014/11/26/agenda-for-november-26th-dev-chat/

Misses

  • BetaBeta 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

  • Beta 2 (soft-released)

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 UXUX 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.comWordPress.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 migrationMigration 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 pluginPlugin 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

Continue reading

Multisite Office Hours (Redux)

Several months ago, @wonderboymusic proposed office hours for Multisite. The response was great, but we kind of laxed on making it happen after the first one or two.

After talking with a few people at WCSF last month, I’d like to fire this up again. As Scott mentioned before, there is no master plan, though there is a roadmap.

We do have some interesting things that should be on the front of our minds:

  • What does a trusted networknetwork (versus site, blog) look like? #30145 introduced the concept and we need to figure out where to take it.
  • What kind of improvements could/should be made with a “feature as a pluginPlugin 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”? This may help to jump start some ideas, even if they aren’t merged into coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. immediately.
  • What steps should we take toward multi network? #29415 comes to mind immediately for a likely inclusion in 4.2. #30294 is another example.
  • Unit tests. I’d like to continue doing things like #30080 to really expand how we’re testing multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site.

Let’s do our first office hours at 20:00 UTC this coming Tuesday (November 25). We can decide then if it’s appropriate.

/cc’ing some that are likely interested – @ethitter, @johnjamesjacoby, @johnbillion, @ipstenu, @earnjam – but this is by no means a complete list.

Please stop by in #core on Tuesday and comment away on this post with other things you have your eyes on.

#multisite

Dev Chat Summary, November 19th

https://make.wordpress.org/core/2014/11/19/agenda-for-november-19th-dev-chat/

https://wordpress.slack.com/archives/core/p1416430816002052

Hits

  • BetaBeta 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/coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..
  • Beta 2 will be tagged on Thursday.
  • Release Candidaterelease 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 tagtag 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 pluginPlugin 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

TaxonomyTaxonomy 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 bugbug 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 puntpunt 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 compatback 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 i18ni18n 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 localeLocale 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 TracTrac 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 sidebarSidebar 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 CSSCSS 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 RCrelease 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). 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 loopLoop 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: adminadmin (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 trunktrunk 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 edgebleeding 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 SVNSVN 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 ticketticket 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 (APIAPI 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

Open Update Thread, Week of November 17th

What’s going on?

#open-update-thread

Open Academy Mentorship Progam

Hi all. It was suggested by a community member that we participate in the upcoming Facebook Open Academy mentorship program round the way we participate in GSoC. Since I’m on my way out, I wouldn’t be the organization contact for this, and someone would need to step up from the team to take point if y’all want to be a mentoring organization. Here’s some info:

  • This is a Facebook program, run in conjunction with a dozen or so universities around the world and a handful of OS projects.
  • It sounds like they are looking for the mentor to work with the students using Agile sprints.
  • No set time for specific projects, could last anywhere from 8 weeks to 5 months.
  • You set the specific projects in advance students can apply for, no “send us your ideas” like GSoC.
  • Their application asks how many students we can take, must be a minimum of four, but doesn’t have a way to list out all potential mentors up front unless so am not sure if they want each one to fill in the whole application (we’d probably want to have everyone use the same boilerplate for the ‘about the project’ bits), or if they want only one official mentor and everyone else would be unofficial.
  • Mentors must be available to fly to the opening weekend sprint Jan 30-Feb 1 (Facebook pays travel).
  • Students get college credit toward their CS degrees, not money.

General Information
FAQ
Application

If you want to participate, it would be good to have one person be the program administrator to keep track of applications etc. If you decide to do it and want any help from the community team, let me know.

#mentorship, #open-academy

JS/Underscore-template-rendered Custom Customizer Controls in WordPress 4.1

The CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. is a JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/.-driven feature of WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., but until recently, most of the APIs for extending it in themes and plugins were PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher-oriented. In WordPress 4.1, we’re introducing more complete JS models for the different UIUI User interface objects that comprise the Customizer. In the process, all controls are now placed into the DOM with JavaScript, rather than being output directly in PHP.

At the same time, we’ve been working on issues of scalability and performance. In particular, bringing the navigation menu management experience into the Customizer has highlighted several areas with room for improvement. With menus, each menu item is a Customizer control with several fields, so a site with hundreds of menu items across different menus will end up sending a lot of repetitive HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. down from PHP, and we currently have to send the full markup for a menu item control down from the server when adding menu items in an Ajax call.

#29572 offered a solution to these challenges: an optional APIAPI 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. that allows Customizer controls to be written as JavaScript templates. Rather than populating a control’s container with markup rendered on the server and obtained via an Ajax call, we can now use JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. templates to render these controls on the client without any server-side call. In the future, new controls could be added dynamically (lazy-loaded, #28580) by leveraging the control-type templates already loaded in the Customizer.

In the remainder of this post, I’ll walk through how to use this API, its benefits, and example use-cases that are already benefiting WordPress core in 4.1.

Registered Control Types

In order to introduce a concept of having one template for multiple Customizer controls of the same type, we needed to introduce a way to register a type of control with the Customize Manager. Previously, custom control objects were only encountered when custom controls were added using WP_Customize_Manager::add_control(). But detecting added control types to render one template per type wouldn’t allow new controls to be created dynamically if no other instances of that type were loaded. So we’ve introduced WP_Customize_Manager::register_control_type(). Usage is simple:

add_action( 'customize_register', '29527_customize_register' );
function 29527_customize_register( $wp_customize ) {
	// Define a custom control class, WP_Customize_Custom_Control.
	// Register the class so that it's JS template is available in the Customizer.
	$wp_customize->register_control_type( 'WP_Customize_Custom_Control' );
}

All registered control types will have their templates printed to the Customizer by WP_Customize_Manager::print_control_templates().

Sending PHP Control Data to JavaScript

While Customizer control data has always been passed to the control JS models, and this has always been able to be extended, you’re much more likely to need to send data down when working with JS templates. Anything that you would want access to in render_content() in PHP will need to be exported to JavaScript to be accessible in your control template. WP_Customize_Control exports the following control class variables by default:

  • type
  • label
  • description
  • active (boolean state)

You can add additional parameters specific to your custom control by overriding WP_Customize_Control::to_json() in your custom control subclass. In most cases, you’ll want to call the parent class’ to_json method also, to ensure that all core variables are exported as well. Here’s an example from the core color control:

public function to_json() {
	parent::to_json();
	$this->json['statuses'] = $this->statuses;
	$this->json['defaultValue'] = $this->setting->default;
}

JS/Underscore Templating, + examples

Once you’ve registered your custom control class as a control type and exported any custom class variables, you can create the template that will render the control UI. You’ll override WP_Customize_Control::content_template() (empty by default) as a replacement for WP_Customize_Control::render_content(). Render content is still called, so be sure to override it with an empty function in your subclass as well.

Underscore-style custom control templates are very similar to PHP. As more and more of WordPress core becomes JavaScript-driven, these templates are becoming increasingly more common. Some sample template code in core can be found in media, revisions, the theme browser, and even in the Twenty Fifteen theme, where a JS template is used to both save the color scheme data and instantly preview color scheme changes in the Customizer. The best way to learn how these templates work is to study similar code in core and, accordingly, I’ll briefly explain an example here now.

class WP_Customize_Color_Control extends WP_Customize_Control {
	public $type = 'color';
// ...
	/**
	 * Render a JS template for the content of the color picker control.
	 */
	public function content_template() {
		?>
		<# var defaultValue = '';
		if ( data.defaultValue ) {
			if ( '#' !== data.defaultValue.substring( 0, 1 ) ) {
				defaultValue = '#' + data.defaultValue;
			} else {
				defaultValue = data.defaultValue;
			}
			defaultValue = ' data-default-color=' + defaultValue; // Quotes added automatically.
		} #>
		<label>
			<# if ( data.label ) { #>
				<span class="customize-control-title">{{{ data.label }}}</span>
			<# } #>
			<# if ( data.description ) { #>
				<span class="description customize-control-description">{{{ data.description }}}</span>
			<# } #>
			<div class="customize-control-content">
				<input class="color-picker-hex" type="text" maxlength="7" placeholder="<?php esc_attr_e( 'Hex Value' ); ?>" {{ defaultValue }} />
			</div>
		</label>
		<?php
	}
}

In the above template for the core custom color control, you can see that after the closing PHP tagtag 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.), we have a JS template. <# #> notation is used around statements to be evaluated – in most cases, this is used for conditionals. All of the control instance data that we exported to JS is stored in the `data` object, and we can print a variable using double or triple brace notation {{ }}. As I said before, the best way to get the hang of writing controls like this is to read through existing examples. WP_Customize_Upload_Control was recently updated to leverage this API as well, integrating nicely with the way the media manager is implemented, and squeezing a ton of functionality out of a minimal amount of code. If you want some really good practice, try converting some of the other core controls to use this API – and submit patches to core too, of course!

Working with Controls in JavaScript

The Customizer has always had an API for working with controls in JavaScript. Now that the Customizer supports JS-rendered controls, this API will be even more useful, as you can do things like re-rendering the entire control if its data changes significantly (think media attachment previewing, for example), rather than doing direct DOM manipulation. Again, the core code is the best place to start getting a feel for this API, but it essentially works like subclasses do in PHP. See @westonruter‘s post for details on how this side of the API has evolved in 4.1, and take a look at the control-related models in wp-admin/js/customize-controls.js.

Putting the pieces together

Here’s a summary of what’s needed to leverage the new API in a custom Customizer control subclass:

  1. Make your render_content() function empty (but it does need to exist to override the default one).
  2. Create a new function, content_template(), and put the old contents of render_content() there.
  3. Add any custom class variables that are needed for the control to be exported to the JavaScript in the browser (the JSONJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. data) by modifying the to_json() function (see WP_Customize_Color_Control for an example).
  4. Convert the PHP from render_content() into a JS template, using <# #> around JS statements to evaluate and {{ }} around variables to print. PHP class variables are available in the data object; for example, the label can be printed with {{ data.label }}.
  5. Register the custom control class/type. This critical step tells the Customizer to print the template for this control. This is distinct from just printing templates for all controls that were added because the ideas are that many instances of this control type could be rendered from one template, and that any registered control types would be available for dynamic control-creation in the future. Just do something like $wp_customize->register_control_type( 'WP_Customize_Color_Control' );.

The PHP-only parts of the API are still fully supported and perfectly fine to use. But, with WordPress 4.0’s decreased need for custom controls, and given our long term goals for making the Customizer more flexible for doing things like switching themes in the Customizer without a pageload, I strongly encourage using this new API for all custom Customizer controls where feasible.

#4-1, #customize, #dev-notes, #menu-customizer, #menus