PHP Meeting Recap – April 23, 2018

This recap is a summary of our previous PHP meeting. It highlights the ideas and decisions which came up during that meeting, both as a means of documenting and to provide a quick overview for those who were unable to attend.

You can find this meeting’s chat log here.

Chat Summary

The main focus of our recent meeting was reviewing the latest work around the upcoming php info widget.  A reminder that this work is being tracked here.

  • @schlessera presented the latest iteration of the widget for feedback which is this:
php widget screenshot 1

collapsed version:

php widget screenshot 2

Notable features of this iteration:

  • It is accessible.
  • It is more in line with the other widgets.
  • It makes the widget more noticeable when collapsed.
  • It makes use of a dash-icon instead of a notice border for drawing attention

General consensus seemed to favor this latest iteration.  However @johnjamesjacoby brought up some concerns about the verbiage and  language still in the widget.

  • Unnecessary “Click the button” type guidance
  • Running an insecure version of PHP doesn’t mean that a quicker website is a quick update away. (Note, this feedback was also left as a comment in the previous meeting summary post.)
  • Unusual for WordPress core verbiage to have “this is how we do it” type phraseology.

Responses were:

  • Let’s get this feedback on the trac ticket.
  • While most of us don’t completely like what we have now, it’s been through multiple iterations including incorporating suggestions from design and editorial teams.  So its “good enough” for now and we can iterate.

In the latter part of the meeting we focused on the following design comments:

  • Use the color red only if insecure version, otherwise use yellow/orange.
  • Collapse the nag by default.

Although it was brought up that it’s unlikely yellow/orange would ever be displayed because most scenarios will result in an insecure version of PHP prompting the widget to show, we agreed that its trivial to do conditional colors so it will be implemented.

However, the nag being collapsed by default is not a trivial change to make.  There’s no prior art for that with the dashboard widgets.  We decided to defer further discussion on this until the next meeting.

After Hours

Since the meeting @johnjamesjacoby provided additional feedback in the trac ticket and @flixos90 took some of what he suggested and proposed another iteration for the widget:

PHP widget - latest iteration.

Changes made in this iteration:

  • Fix incorrect statement “WordPress has detected that your site is running on an insecure version of PHP, which means that a faster website is just a quick update away.” by removing the second part of that sentence. That furthermore makes it a more clear statement, and the aspect of speed is mentioned in the second paragraph anyway.
  • Remove the whole last section that essentially just revolves around the user needing to click the button. It helps further shortening the copy, as requested by the design team, and was redundant.
  • Left-align button and make it regular-size, as requested by the design team and in 41191.11.2.diff@johnjamesjacoby We cannot shorten the button text itself, as “Learn more” makes it too unclear this link helps with updating PHP.
  • If the PHP version is not insecure, but only out-of-date, show the icon with yellow color, as requested by the design team. This change is to be future-proof, but note that at this point, it will never be rendered this way because we show the notice only on 5.2 which is insecure.

Next meeting:

Next meeting will take place on Monday April 30, 15:00 UTC in #core-php


  • Followup on the latest iteration of the php widget.
  • Decide on whether the widget will default to collapsed.

A reminder that if you have suggestions about the dashboard widget but cannot make the meeting, please leave a comment on this post (and/or comment in the trac ticket).

Multisite Recap for the week of October 2nd

Office Hours Recap

The agenda for this office hours meeting was to prepare remaining open enhancements for the 4.9 release.

The meeting’s chat log

Attendees: @flixos90, @spacedmonkey, @jeremyfelt

Chat Summary:

  • #40228 – Review the latest patches for using get_site_by() in get_blog_details().
  • #40201 – Review the latest patches for using get_site() in clean_blog_cache(). @flixos90 and @jeremyfelt agreed that requiring a site ID is okay for clean_blog_cache(), moving the refresh_blog_details hook into clean_blog_cache() is appropriate, and deprecating the refresh_blog_details hook in favor of clean_site_cache is good.
  • @flixos90 committed to committing #40201 and #40228 before 4.9 beta.
  • #42072 and #42073 – Discussed both of these, which involve limiting get_sites() calls to 1 result when only 1 result is used. @jeremyfelt took ownership of these for 4.9.
  • #41762 – Agreed to use WP_Network_Query in ms_load_current_site_and_network(), but to keep the current-network cache key for now.

Next meeting

The next office hours will take place on October 4, 2017, 16:00 UTC. Its agenda will be to go over remaining bugs for 4.9 and the progress of this cycle’s dev notes.

Ticket Scrub Recap

The agenda for this ticket scrub was to review remaining enhancements for the 4.9 release.

The meeting’s chat log

Attendees: @ramiy, @sergey, @afragen, @flixos90, @spacedmonkey, @jeremyfelt, @johnjamesjacoby, @desrosj

Chat Summary:

  • #40180 – Discussion on some of the remaining details for get_site_by().
  • #40228 – Agreed to finish and commit #40180 so that the patches for get_site_by() in get_blog_details() would be easier to review.
  • #40201 – Discussion if clean_blog_cache() should support an empty argument as a replacement for refresh_blog_details(). Agreement that it’s okay to continue requiring that a site be specified.
  • Discussion on when or whether to deprecate refresh_blog_details() or its hook refresh_blog_details, which is now a part of clean_blog_cache(). It seems that it’s okay to postpone this until get_site_by() and clean_blog_cache() are more widely used.

Next meeting

@jeremfelt did not clarify early enough whether or not a ticket scrub will take place on October 3, 2017, 17:00 UTC. 🙈 A loose agenda would be to cover remaining bugs for the 4.9 cycle.

If you were unable to attend one of these meetings but have feedback, please share your thoughts in the comments on this post. In case there’s a need for further discussion we will ensure to make time for it in one of next week’s chats. See you next week!

#4-9, #multisite, #network-sites, #summary

Multisite Recap for the week of September 11th

Office Hours Recap

The agenda for this office hours meeting was to resolve the remaining discussion and blockers for #29684, the proposed get_main_site_id() function and related integration.

The meeting’s chat log

Attendees: @afragen, @desrosj, @flixos90, @jeremyfelt, @johnjamesjacoby, @spacedmonkey

Chat Summary:

  • The main purpose this function could serve initially is to auto-fill the $blog_id property of the WP_Network class, which currently is only being populated for the current network in the bootstrap process. There is no database field for the main site of a network, therefore custom logic must run for it to be set. get_main_site_id() makes it easy to detect the main site for a network, and magic getters in WP_Network would allow to automatically set the property once it is first accessed, using the new function. In the end of the discussion it was decided that the logic to auto-fill the property makes sense and can be merged with the new function.
  • It was also discussed whether a network option should be used to store the main site ID. This would bring a performance benefit for multisite setups without an object cache and without the network constants enabled. On the other hand, the main site ID at this point is not really an option, since many areas of WordPress assume it is always the site whose domain and path match the network’s ones. Getting rid of this restriction is something that could be evaluated more closely in the future, but for now this restriction exists, and introducing a network option would give the impression that it would be possible to change the main site ID without any issues. Therefore it was decided to not use a network option at this point, but it can be reconsidered later in a separate ticket.
  • Another topic was whether the actual logic should go into the get_main_site_id() function or whether the function is not required at all and instead the logic should be part of WP_Network. Eventually it was agreed to go with the regular function and call it from WP_Network. Moving the logic into a private WP_Network method would not align well with existing core patterns, where pretty much everything relies on a function. As long as there is no methodological approach for this, functions should remain the source as it currently is.
  • Naming of the new function was discussed as well. It was suggested to call the function get_main_site_id_for_network() or get_network_main_site_id() to be more precise. On the other hand, is_main_site() already exists and would have been called similarly in order to align with the new function. Furthermore the function is available for non-multisites, making the extra network affix a bit more confusing. It was decided to proceed with the current idea of get_main_site_id().
  • All remaining items were solved and as of now the patch has been merged into core.

Next meeting

The next office hours will take place on September 19, 2017, 16:00 UTC. Its agenda will be to further plan 4.9 work and which tickets should receive the main focus in the few remaining weeks until Beta 1.

Ticket Scrub Recap

The agenda for this ticket scrub was to review and discuss some multisite tickets in the 4.9 milestone.

The meeting’s chat log

Attendees: @afragen, @desrosj, @flixos90, @jeremyfelt, @sergey, @vizkr

Chat Summary:

  • The first ticket discussed was #40764: @afragen asked for feedback. @flixos90 verified that the latest patch applies cleanly. @desrosj plans to review the patch itself soon.
  • #41285 was discussed: @jeremyfelt was asked for feedback and responded that he is confident that this change can happen, at least for the $public global. He will dive deeper into whether the $site_id global is safe to remove as well. He furthermore stated that the related tickets #34217 and #39419 should be considered as well. A response from Automatticians working on would be much appreciated.
  • #40364 was the last ticket for the meeting: The proposed action hook names used in the new functions wp_insert_site(), wp_update_site() and wp_delete_site() using the same names were questioned and whether it may be more useful to use more precise names using past tense, such as wp_inserted_site(), so that it is clear they run after the database transaction. It was also considered to run multiple actions. Eventually it was decided to go with the simple approach for now, and stick with one action having the function name. Regarding timing, while the latest patch may possibly be merged at this point, it should rather wait until #41333 has also been completed, to have the full new site API in core in one release. The latter ticket is something that can be worked on during the 4.9 beta, to aim for an early 5.0 merge.

Next meeting

The next ticket scrub will take place on September 18, 2017, 17:00 UTC. Its agenda will be to review multisite bug tickets awaiting review with a focus on recently opened tickets.

If you were unable to attend one of these meetings but have feedback, please share your thoughts in the comments on this post. In case there’s a need for further discussion we will ensure to make time for it in one of next week’s chats. See you next week!

#4-9, #multisite, #networks-sites, #summary

WCEU & Weekly Multisite Chat Summaries

During lunch at WordCamp Europe, there was an informal discussion with some contributors who have an interest in multisite. This post is meant to summarize those discussions and create a plan for organizing and improving the multisite component moving forward.

Present for discussions: @flixos90 @stephdau @spacemonkey @desrosj

Weekly Component Dev Chats

Because all contributors cannot be present every week, there have been a few instances where deep discussions have reoccurred in consecutive weeks due to a different set of people being present. This has slowed progress, and also limited feedback to only those who can attend.

The meeting discussions sometimes veer off course to items that are not necessarily a part of the current component goals. Weekly bug scrubs have also on occasion turned into detailed discussions (more on this later).

For these reasons the following items were proposed:

  • Post a meeting agenda weekly at least one full day prior to scheduled dev chats.
  • Post a meeting summary after the meeting.

The meeting agendas will help keep the conversations on target and ensure they are productive. They will also help contributors decide which meetings they want and need to attend. If someone has anything that they would like to contribute but is unable to attend, they can post a comment on the agenda post.

The meeting summaries will help inform all who were unable to attend by communicating what was discussed. It will also help prevent discussions from reoccurring in consecutive weeks when a different set of contributors are present. Anyone can also comment on the meeting summary with any additional feedback. If there is a lot of feedback on the summary, the topic can be slated for more discussion during the following week’s dev chat.

These two things have proven effective for both the Core and JavaScript chats, and should also help the multisite component.

Multisite Roadmap

In an ongoing effort that will continue through the next couple weeks, a component roadmap is being discussed. Roadmaps are great for identifying the current problems that should be solved in a general order and establishing a direction. The roadmap should also describe why each problem needs solving with examples, and what steps potentially could be taken to reach a solution.

By listing out the goals and needs of the component in the rough order they should be tackled, dev chats can be more targetted and the component can progress more effectively.

Currently, the primary goals of the multisite component are implementing a REST API endpoint for sites and improving the user endpoint to support all multisite functionality. It is also likely that a networks API endpoint will be introduced, although that is a lower priority than the other two. Sites and networks are the only WordPress core component without a REST API endpoint.

Information Sharing

Since has had a Sites endpoint for quite a while now, @stephdau shared some links after the meeting with the other attendees. He emphasized that nothing there is secret and there is a desire to share information and collaborate. He also stated that much of the code is actually packaged in Jetpack.

Ticket Gardening

As of this being published, there are 160 bug tickets for the multisite component in Trac. It would be great to decrease this. As mentioned above, weekly bug scrubs occasionally turn into continuation discussions of the previous dev chat. Having specific ticket lists to work through on a given day may help more effectively manage tickets belonging to the component, gardening them into the appropriate milestones.

@johnbillion also mentioned in a separate discussion that he has an offline list of multisite bugs that he has noticed. He will be going through Trac at some point to ensure each issue has a Trac ticket (although most already do).

Follow Up

As a follow-up to this meeting, @flixos90 created a Google Doc to help collect thoughts and serve as an organizational document for the multisite component.

Weekly Office Hours

The meeting’s chat log

Attendees: @jeremyfelt @flixos90 @johnjamesjacoby @desrosj @sergey @spacedmonkey @saracannon @stephdau @earnjam

This week’s office hours were used to recap the discussions above and gather further input. @flixos90 shared the Google Doc linked above, and then discussions were had to determine if the policies roughly outlined are viable for common procedures in multisite. Eventually, after the necessary tweaks are made to the document, it will be posted on this blog and on the Networks and Sites component page. This will ensure more permanent visibility and also allow other components to possibly follow some of the ideas for their workflows as well.

Key points summarized from the document by those who were at WCEU:

  • Not repeating ourselves week to week is important. Meeting recaps will inform people who cannot attend office hours. Agendas will keep meetings focused.
  • Responsibility for creating agenda and recap posts (especially the recaps as they’re more work) should rotate between multiple contributors. This is a great way to help onboard new contributors and foster interest in the component.
  • There should be more targeted ticket lists to focus on during bug scrubs. Try to tackle the ones that relate to our roadmap goals and properly prioritize.

At times, the component does get a little slow. Even during these times, an agenda should still be posted. It was also decided that there should be one agenda post (stating the agenda for both the week’s upcoming bug scrub and office hours), and one summary per week. Having consistent agendas will help us stay on target. Establishing a roadmap as needed will also help. “The multisite group is currently focusing on these 3 things from X date to X date” could be a useful way to clearly state the current goals. This would fit well on the component page.

It was decided to change “bug scrub” to “ticket scrub” as it is not limited to discussing bugs. Also discussed was having people who can focus only on bug fixes without needing to worry about when new features will land around them. This would be very helpful to the component. Current contributors each have different strengths and utilizing these strengths effectively should be a priority.

Increased documentation around why decisions are made needs to happen. This will help future contributors understand why specific actions are taken, and why certain features are implemented how they are.

Better utilizing Trac’s “good first bug” was discussed. These tickets are very helpful for picking up new contributors and giving them a positive experience contributing to the component. Ensuring that good first bugs are in fact easy to fix is important. Good first bug tickets should not remain open for multiple releases though. Otherwise, there is a risk for a negative experience when the contribution is not immediately accepted. There was, however, some disagreement on this. Leaving easy fix tickets could be counter-productive.

There was also some post-meeting discussion about making multisite contributions to core easier. Currently, VVV does not allow a multisite install to be created using trunk. This would make writing and testing patches much easier.

Next week, @flixos90 will run office hours. @spacedmonkey will run office hours the week after that. The rough plan for office hours the next three weeks is:

  • Continued discussion on component organization and, afterward, on the sites API
  • Site meta
  • Network meta

Next week’s ticket scrub will focus on tickets without a response followed by tickets awaiting review.

To conclude the meeting, @spacedmonkey was officially approved as a component maintainer. Congratulations!

If you’re interested, please come to our meetings or leave a comment on this post with your thoughts. Multisite office hours are held every Tuesday at 16:00 UTC, while our ticket scrub is held every Monday at 17:00 UTC, both in #core-multisite. The next ticket scrub will be Monday 17:00 UTC and the next office hours will be Tuesday 16:00 UTC.

#multisite, #networks-sites

JavaScript Chat Summary for May 30th

Foreword: The topic of integrating a new JavaScript framework in WordPress has proven to be both lively and contentious. The summary that follows is a best effort at an objective and accurate recap, but you are encouraged to review the original Slack transcript for the complete unaltered context (Slack registration required).

Below is a summary of the discussion from today’s JavaScript chat (agenda, Slack transcript, last week’s summary):


  • The conversation that followed from last week has taken heavy aim at considering only React and Vue as candidates. Have we been certain to exhaust all other options?
  • Backbone features will continue to be maintained in core for the foreseeable future
  • The decision to be made is one affecting new features to be built
  • Developers will still have flexibility in choosing their preferred tools for themes and plugins
  • We need to know what we’re building in order to make sound technical decisions. This year’s focuses can serve as a start: the post editor (Gutenberg), Customizer expansion in moving toward theme building functionality, and REST API-based reimplementations of existing features (examples including Quick Draft, post listing)

Alternative Suggestions

  • Deciding on React as the framework of choice in Calypso was the result of prototype implementations of various frameworks (at the time, 3+ years ago) and judging the success of each.
  • Preact could serve as a stand-in for a React-like paradigm if we consider ourselves blocked by React’s patent grant or ideological differences between Facebook the company and WordPress the project.

Contrasting Candidates for Consideration

The bulk of the conversation considered the merits of React and Vue only, largely contrasted on the basis of developer onboarding, ideological alignment between WordPress and for-profit companies, and the extent to which each sets the foundation for successful future maintenance of the features we seek to implement.

  • Vue in practice: There have been no examples surfaced for projects relating to WordPress and the sorts of features we want to build (examples welcome in comments).
  • Ideological implications: We should consider what it means to align WordPress with any particular framework. There’s a worry that the values of Facebook as a company are at odds with those of WordPress.
  • Concerns about React: its learning curve and licensing (specifically, a termination clause included in its patent grant)
  • React is a pattern as much as it is a library, as evidenced by proliferation of compatible libraries like Preact, Inferno, Rax, and others.
    • Patterns emphasizing declarative rendering, one-way data flow, and embracing JavaScript the language. WordPress has historically stayed true to the fundamentals of the languages, largely foregoing template languages or other domain-specific languages in PHP.
  • Embracing JavaScript the language
    • Building rich applications is not comparable to history of applying JavaScript minimally in small interactions. Modern JavaScript is necessarily more involved to learn than a library like jQuery because we are building more complex functionality.
    • Are we really setting a foundation for developers to succeed into the future if we obscure the language with a template language like Vue’s (logic example)? Are we being inviting to new developers who began programming using JavaScript, or providing skill-learning opportunities that are broadly applicable?
    • Vue offers render functions similar to React, but their existence could undermine the perception of Vue being simpler if we’re acknowledging that the limits of the framework necessitate additional paradigms encompassing the entirety of React. Or is the argument of React’s complexity something else?
  • Conversely, there is a strong sentiment that Vue has a much friendlier developer onboarding experience. WordPress has prospered by its approachability, and our patterns in JavaScript should reflect this too. Vue’s documentation is undeniably superb.
    • Regardless of any framework decision, making educational resources available will be important
  • The role of corporate backing: Is Facebook’s investment in React a benefit in its supporting longevity of the project, or would it hold us hostage to the whim of their decision-making?
    • Vue is largely maintained by a single contributor (related: bus factor) funded via Patreon to work full-time on the project
    • It is not in Facebook’s interest to make large backwards-incompatible changes, because they too would suffer in their maintenance of hundreds of thousands of components across their products
  • On the complexity of React: is this more accurately attributed to supporting tooling? Specifically build tools like Webpack, and patterns for state management like Redux. For better or worse, React is largely unopinionated on architecture not affecting view rendering.
    • Would we need similar tooling for Vue? Both Vue and React offer no-tooling-required options, but both also push developers toward a build process (single file components for Vue, JSX for React)
    • Is build configuration something that we’d expose to developers anyways? Maybe not for the configuration itself, but a build process generally limits ability to directly modify files on a remote server.
    • Build tooling could be a worthwhile inevitably for developers to learn
  • Readability: Vue components may be more readable for new developers because they leverage HTML-like elements and attributes
  • Approachability: Ease of getting started can be a double-edged sword if it fails to teach fundamentals of the language that would be necessary for continued maintenance. The demands of rich interfaces necessitate a deep understanding of the language.
    • At the same time, we must not ignore that WordPress would not be where it is today if not for its ease of getting started. If we achieve maintainability but nobody is willing or capable to maintain it, then nothing is accomplished.
  • To differing sentiments between the developer chat and resulting commentary on last week’s summary: there are clear React leanings observed in the Slack chat, whereas the summary comments largely favored Vue.
    • How can we disassemble surface-level claims of “complex” and “simple” into a detailed understanding of why these feelings exist?
  • The broad impact of choosing a framework: Plugin and theme authors should have the freedom and flexibility to choose their desired tool.
    • In this framing, it should primarily be a decision of core contributors to make if it is they who are to be affected.
    • But is a framework decision going to count as a vote of confidence and unnecessarily skew perceptions one way or the other to choosing the best tool for the job?
  • Learning from the past: Why does Media Library see so few contributions? What lessons can we learn from this to avoid having this conversation again in a few years time, or is that an inevitability?
  • Future compatibility: Templating languages tend to have short lifespans. An example was raised of a Vue 2.0 breaking change regarding v-for as evidence suggesting that deviations from the core language are subject to change and therefore undermine stability. Learning the syntax of a language can be simple at the cost of understanding the underlying flow of data.
  • Process for adoption: A rewrite is unfeasible, and therefore modularity is an important consideration. Do we see the future dashboard as a collection of small applications, or a monolithic single-page application? There appear to be differing opinions on this.
    • Instead of rushing to adopt a new framework, where can we find ways to reduce our footprint, especially in light of revised browser support?

Conclusion and Action Items

With WordCamp Europe quickly approaching and this conversation having encompassed two JavaScript chats, it’s expected that a review of the discussions and formulation of action items should take place during the WCEU contributor day and at the Community Summit.

The topic of next week’s JavaScript chat will not focus on this decision, but you are encouraged to leave your comments below relating to this week’s topic or a suggestion for next week.

#javascript, #summary

Week in Core, April 19th – April 25th 2017

Welcome back the latest issue of Week in Core, covering changes [40476-40556]. Here are the highlights:

  • 81 commits
  • 29 contributors
  • 90 tickets created
  • 11 tickets reopened
  • 48 tickets closed

Ticket numbers based on trac timeline for the period above. The following is a summary of commits, organized by component.

Code Changes


Build/Test Tools

  • Feeds: Remove an incorrect usage of sizeof() in a helper class used during unit testing of XML element handling. [40555] #40109
  • Add Composer files to the cache on Travis. [40554] #40539
  • Backport various recent changes to the 4.7 branch. [40547] #40539, #39822, #40548
  • Remove HHVM from the test infrastructure on Travis. [40546] #40548
  • Remove more unnecessary test skipping when erroneous situations occur. [40544] #40533
  • Introduce skipWithoutMultisite() and skipWithMultisite() methods into the test suite. [40543] #40531
  • More tweaks to the deprecated calls assertion. This needs to be triggered when there are unexpected deprecated calls or wrongdoings too. [40542] #40538
  • Only perform an assertion for deprecated calls and wrongdoings if any are expected. [40541] #40538
  • Move the setExpectedException() method into the WP_Ajax_UnitTestCase class to avoid a fatal error when PHPUnit 3.6 is in use. [40539] #39822
  • Add support for PHPUnit 6+. [40536] #39822
  • Ensure that WP_UnitTestCase::expectedDeprecated() performs an assertion to avoid risky test notices. [40535] #40538
  • Be strict about tests that do not test anything. [40534] #40538
  • Remove unnecessary checks and skips that should instead cause failures if they ever fail. [40533] #40533
  • Convert more test skipping into hard failures. These dependencies should all be present when testing. [40532] #40533
  • Correct an incorrect ms- group name. [40530] #40531
  • Add some locale debugging to the Travis config so we can determine which locales are available to test with. [40528] #40533, #19861
  • Enable verbose mode in PHPUnit so we can see which tests are being skipped, and now that the number of skipped tests has been lowered. [40527] #40533, #40531
  • Don’t trigger a skipped test when the built version of wp-embed.min.js isn’t present. [40526] #34698, #40533
  • Replace test skipping with actual assertions when dealing with the DISALLOW_UNFILTERED_HTML, DISALLOW_FILE_MODS, and DISALLOW_FILE_EDIT constants. [40525] #40533
  • Remove more skipped tests that should actually be failures if their conditions aren’t satisfied. [40524] #40533
  • Remove ancient UT ticket handling. [40523] #40533
  • Add some more tests to the ms-required and ms-excluded groups. [40522] #40531
  • Introduce ms-required and ms-excluded groups for tests. [40520] #40531
  • Don’t skip tests when or are unreachable. [40519] #40533
  • Avoid skipping canonical tests that are connected to open Trac tickets. [40518] #30284, #40534
  • Canonical: Don’t skip tests if the test data is invalid. [40517] #40533




  • TinyMCE: Fix cursor position after updating a wpview node. Fix hiding the inline toolbar on editor blur. [40482] #40480
  • Define $suffix before using it in _WP_Editors::print_tinymce_scripts(). [40477] #40479, #35760
  • Provide API for the editor to be dynamically instantiated via JS. First run. [40476] #35760


  • Accessibility: Make Safari 10 + VoiceOver announce repeated, identical, wp.a11y.speak() messages. [40479] #36853


  • Fix typo in help text on Reading Settings screen. [40540] #40530


Networks and Sites

  • Multisite: Add $network_id parameter to wp_update_network_counts(). [40486] #40386, #38699
  • Multisite: Add $network_id parameter to wp_update_network_user_counts(). [40485] #40349, #38699
  • Multisite: Add $network_id parameter to wp_update_network_site_counts(). [40484] #37528, #38699
  • Multisite: After [37918] add support for retrieving custom site properties set by the site_details filter. [40478] #40458

Posts, Post Types

  • Correct the fallback value for the label_count argument of register_post_status(). [40516] #38686



  • Restore support for taxonomy ‘args’ override when querying object terms. [40514] #40496
  • Docs: Improve @param and @return entries for wp_get_post_categories(), wp_get_post_tags(), and wp_get_post_terms(). [40483] #40481



Thanks to @csloisel, @afercia, @Arena94, @azaozz, @bhargavbhandari90, @boonebgorges, @celloexpressions, @danielbachhuber, @darthaud, @dd32, @flixos90, @gitlost, @imath, @iseulde, @johnbillion, @johnjamesjacoby, @littler.chicken, @miyauchi, @ocean90, @peterwilsoncc, @philipjohn, @PieWP, @raisonon, @SergeyBiryukov, @swissspidy, @theMikeD, @timmydcrawford, @westonruter, and @xrm for their contributions!


Week in Core, March 29th – April 4th 2017

Welcome back the latest issue of Week in Core, covering changes [40348-40375]. Here are the highlights:

  • 28 commits
  • 29 contributors
  • 81 tickets created
  • 8 tickets reopened
  • 51 tickets closed
    Ticket numbers based on trac timeline for the period above. The following is a summary of commits, organized by component.

Code Changes


Bundled Theme

  • Twenty Seventeen: Use esc_attr_e() for translatable strings in HTML attributes. [40374] #40216
  • Twenty Seventeen: Declare jQuery as a dependency for navigation.js. [40373] #40224



  • Change the embed_autourls option filter from default_option_* to pre_option_* to avoid a DB query. [40360] #38924


  • Remove an extra slash between .mo file path and name in load_muplugin_textdomain(). [40362] #39168


  • Use correct capitalization for PHPMailer methods in wp_mail(). [40363] #39702


  • Accessibility: Improve the Media Library inline uploader accessibility. [40359] #37188

Networks and Sites

  • Multisite: Fix wp_get_sites() to return an unlimited amount of sites when passing a falsy limit argument. [40372] #39879, #35791
  • Multisite: Add $network_id parameter to get_user_count(). [40371] #37866
  • Multisite: Support the $network_id parameter of get_blog_count(). [40370] #37865
  • Multisite: Correct documentation for site status change hooks. [40352] #40287
  • Multisite: Add deleted_blog action after site has been deleted. [40351] #25584

Posts, Post Types

  • Introduce post_date_column_status filter for post status text in list tables’ Date column. [40361] #39545

Press This

  • Reorder post format icon styles for consistency with get_post_format_strings(). [40356] #40304
  • Add missing icons for Chat and Status post formats. [40355] #40304

Quick/Bulk Edit


  • JS Client – Enable connecting to multiple endpoints. [40364] #39683
  • Tests: Remove a couple of invalid error assertions. [40350] #40270


  • Invalidate term query caches when setting or deleting term relationships. [40353-40354] #40306
  • Fix typo in $aria_checked variable name in Walker_Category_Checklist::start_el(). [40348] #40295

Thanks to @adamsilverstein, @afercia, @boonebgorges, @bor0, @chesio, @davidbenton, @dhanendran, @dlh, @ejner69, @flixos90, @iandunn, @jeremyfelt, @jnylen0, @johnbillion, @johnjamesjacoby, @karmatosed, @lucasstark, @mantismamita, @mboynes, @menakas,, @nsundberg, @pauldewouters, @pbearne, @reidbusi, @SergeyBiryukov, @Soean, @swissspidy, and @westonruter for their contributions!


Week in Core, March 22nd – 28th, 2017

Welcome back the latest issue of Week in Core, covering changes [40307-40347]. Here are the highlights:

  • 41 commits
  • 27 contributors
  • 76 tickets created
  • 14 tickets reopened
  • 65 tickets closed

Ticket numbers based on trac timeline for the period above. The following is a summary of commits, organized by component.

Code Changes


  • List Tables: After [38703], [38706], and [40118], adjust the jQuery selector to make the selection of a range of checkboxes work again. [40327] #40056
  • Docs: Add description for $mode global in WP_MS_Sites_List_Table and WP_MS_Users_List_Table. [40310] #40208
  • Docs: Add description for $mode global in WP_Media_List_Table and WP_Posts_List_Table. [40309] #40208
  • Docs: Add missing @global entry for list table view mode in WP_Screen::render_view_mode(). [40308] #40208
  • Docs: Add missing @global entry for list table view mode in wp_ajax_inline_save(). [40307] #40208

Bundled Theme

  • Twenty Seventeen: Declare jQuery as a dependency for navigation.js. [40315] #40224
  • Twenty Seventeen: Use esc_attr_e() for translatable strings in HTML attributes. [40311] #40216

Cache API



  • Tests: Use utf8mb4 max index length when creating keys. [40339] #35958


  • Docs: Correct default value in @param entry for the $num_words parameter of wp_trim_words filter. [40322] #40248

Login and Registration

  • Avoid a potentially incorrect value for the cookie hash on multisite installations that don’t have a value in the siteurl network option. [40320-40321] #34084, #39497

Networks and Sites

  • Multisite: Respect $_wp_suspend_cache_invalidation when clearing network and site caches. [40346] #40028
  • Multisite: Allow falsy properties to be cached in site-details. [40344] #40247
  • Tests: Clarify zero path segment tests for get_network_by_path(). [40342] #37217
  • Multisite: Add lang_id support to WP_Site_Query. [40340] #40196
  • Multisite: After [40305], rename clean_site_details_cache() method as it’s not really private. [40333] #40063
  • Multisite: Add further unit tests for get_blog_details(). [40317] #40228, #40180

Posts, Post Types

  • Add missing REST API properties to WP_Post_Type class. [40329] #39986


  • Tests: Consolidate logic used to skip API fixture generation. [40341] #40041
  • Confirm the parent post object of an attachment exists in WP_REST_Posts_Controller::check_read_permission(). [40337] #39881
  • Add gmt_offset and timezone_string to the base /wp-json response. [40336] #39854
  • Use get_gmt_from_date() when preparing a draft post for response. [40324-40325] #40136


  • Add missing REST API properties to WP_Taxonomy class. [40328] #39987


  • Fix incorrect annotation for __clear_multi_author_cache() function. [40334] #40063, #40262
  • Add filter for excluding directories from being scanned for template files. [40326] #38292


  • Don’t push the current user’s role to the top of the list in wp_dropdown_roles(). [40323] #40162

Thanks to @afercia, @aussieguy123, @bor, @bor0, @caseypatrickdriscoll, @chesio, @clarinetlord, @danielbachhuber, @dd32, @dlh, @flixos90, @GhostToast, @jeremyfelt, @johnbillion, @johnjamesjacoby, @lukasbesch, @michelleweber, @nerrad, @ocean90, @priyankabehera155, @rachelbaker., @redrambles, @sagarkbhatt, @SergeyBiryukov, @swissspidy, and @westonruter for their contributions!


Week in Core, February 22nd – 28th, 2017

Welcome back the latest issue of Week in Core, covering changes [40101-40141]. Here are the highlights:

  • 41 commits
  • 46 contributors
  • 76 tickets created
  • 21 tickets reopened
  • 71 tickets closed

Ticket numbers based on trac timeline for the period above. The following is a summary of commits, organized by component.

Code Changes


Build/Test Tools


  • When commenting on a draft post, display a friendly error message if the user can view the post. [40128] #39650


  • Ensure entities in the site title are decoded when used in the body of the new user email. [40127] #39446



  • Bump the version after the 4.7.3-RC1 packaging. [40141] #
  • Version bump for WordPress 4.7.3-RC1 [40140] #

Networks and Sites

  • Multisite: Use WP_Network_Query in WP_Network::get_by_path(). [40102] #37217

Posts, Post Types

  • Docs: Update the description of is_singular() and WP_Query::is_singular() to be parsed correctly by [40103] #39948



  • Enable browser history support in add new theme screen. [40107] #36613



Thanks to @adamsilverstein, @afercia, @ajoa, @azaozz, @blobfolio, @codegeass, @davidakennedy, @dd32, @desrosj, @Drivingralle, @flixos90, @gitlost, @grapplerulrich, @iandunn, @ipstenu, @iseulde, @jazbek, @jeremyfelt, @jnylen0, @joehoyle, @joemcgill, @johnbillion, @johnjamesjacoby, @JPry, @markoheijnen, @MatheusGimenez, @mayurk, @mikeschroder, @milindmore22, @mnelson4, @netweb, @ocean90, @rachelbaker, @reldev, @ryelle, @sagarprajapati, @sanchothefat, @SergeyBiryukov, @spacedmonkey, @swissspidy, @triplejumper12, @welcher, @westonruter, and @xknown for their contributions!

Providing a REST API sites endpoint for multisite

One of the objectives for multisite is to determine how sites can be managed with the REST API. This has been an agenda item for the last two weeks and quite a bit has been processed. This will continue to be a topic, so please stop in for #core-multisite office hours on Tuesday 17:00 UTC and please leave your feedback in the comments on this post.

January 17 chat log and January 24 chat log in #core-multisite

Attendees: @kenshino, @vizkr, @danhgilmore, @iamfriendly, @flixos90, @schlessera, @sergeybiryukov, @pbearne, @paaljoachim, @streetlamp, @jnylen0, @loreleiaurora, @maximeculea

The requirements for the /sites/ endpoint can be summed up with these assertions:

  • The /sites/ endpoint should provide a useful set of data for each site without requiring the use of switch_to_blog().
  • It should be possible to query /sites/ for something other than ID, domain, and path.

In its current state, any /sites/ endpoint is limited to the fields in the wp_blogs table. Data such as a site’s name and description are stored in each individual site’s wp_#_options table.

Given a list of 20 sites, switch_to_blog() will be used 20 times so that get_option() can be used to retrieve things like home, siteurl, blogname, and blogdescription. An example of how inefficient this is can be found in the generation of the My Sites menu. Caching has gotten better with the introduction of WP_Site and WP_Site_Query, but there is an opportunity to change how the information is stored.

In #37923, @johnjamesjacoby suggests the introduction of a wp_blogmeta table that provides access to some site information in a common table. After discussing this in the January 17 chat, @iamfriendly and @flixos90 agreed to each take a look at core’s default options stored in wp_options and determine which made sense in a shared wp_blogmeta table. Richard’s results can be found in a comment on the ticket and Felix’s in the Slack discussion.

After some discussion in the January 24 chat, that list can be pared down a bit more.

  • home
  • siteurl
  • blogname
  • blogdescription
  • admin_email

The creation of a new table, wp_blogmeta, and migration of data for each site from wp_#_options is something that needs feedback. Without this change, a /sites/ endpoint is still possible, but may be limited. With the change, a /sites/ endpoint is much more useful, but requires a careful migration process.

#multisite, #networks-sites, #rest-api