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 WordPress.com 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 WordPress.com 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 php.net or dev.mysql.com 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, @mt8.biz, @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 developer.wordpress.org. [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

Week in Core, January 11th – 17th, 2017

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

  • 165 commits
  • 44 contributors
  • 87 tickets created
  • 9 tickets reopened
  • 83 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: Pass the $which parameter to restrict_manage_posts filter instance in WP_Media_List_Table, missed in [37422]. [39917] #38772
  • Improve tab character width in Plugins and Themes editor. [39897] #38684

Build/Test Tools

  • Add assertNotFalse() method to WP_UnitTestCase and use it where appropriate. [39919] #39219
  • Correctly reference function names in @covers entries. [39918] #39235
  • After [29858], update .jsintrc to use spaces, not tabs. [39898] #39359

Bundled Theme

  • Twenty Seventeen: Remove duplicate global $post declaration in twentyseventeen_front_page_section(). [39909] #39590
  • Twenty Seventeen: Correct @param entries for twentyseventeen_custom_colors_css filter. [39901] #39575
  • Twenty Seventeen: Remove extra asterisk from a translator comment so the comment could be parsed correctly. [39894] #39116

Cache API

  • Docs: Add missing @param type for wp_cache_get_last_changed(). [39900] #39571


  • dbDelta: Ignore index subparts when checking for duplicate indices. [39921] #34870


External Libraries


  • Tests: wpautop() should not add extra before. [39914] #39307
  • Fix wpautop() to stop adding paragraph tags around “. [39912] #39307


  • Move “Site Language” setting above “Timezone”. [39885] #38562


  • Use a consistent error message for file type errors on uploading. [39891] #33242


  • Post-4.7.1 version bump for 4.7 branch. [39883]
  • Only show major version in readme.html for 4.7 branch [39871]
  • Media: Fix exif_imagetype check in wp_get_image_mime [39851-39861]
  • Tests: Replace broken codeispoetry.png file. [39848-39849]
  • Use plural string ‘Maintenance and Security Releases’ since we have two now [39847]
  • REST API: Change which users are shown in the users endpoint. [39844]
  • Media: Improve image filetype checking. [39832-39842]
  • Updates: Translate plugin data on the Updates screen. [39808]
  • Themes: Fix markup for theme name fallbacks. [39807]
  • Multisite: Use wp_rand() in signup key creation. [39795-39806]
  • Mail: Disable wp-mail.php when mailserver_url is mail.example.com. [39772-39782][39784]


  • Docs: Use a consistent description for $plugin parameter in various plugin API functions. [39890] #36333
  • Docs: Improve the DocBlock for validate_plugin(). [39889] #36333

Posts, Post Types

  • Increase the height of post slug input to prevent certain characters from being cut in Firefox on Windows. [39905] #28084



  • Docs: In wp_set_object_terms(), add a note that passing an empty value as $terms argument will remove all related terms. [39893] #36690

Text Changes

  • Taxonomy: Add an explanation for “Parent” dropdown for hierarchical custom taxonomies. [39895] #23447


  • Add a unit test for get_theme_feature_list() to make sure that the list of theme features pulled from the WordPress.org API returns the expected data structure. [39906] #28121
  • Docs: After [37083], change “HEX format” to “3- or 6-digit hexadecimal form” for clarity. [39888] #36336
  • Use curly braces for variables inside strings in `get_page_template() to explicitly specify the end of the variable name. [39884] #38625


  • Strip browser inserted <u> and <font> tags from inside links when copying and pasting in IE and Edge. [39916] #39570
  • Ensure the inline toolbar is shown and properly positioned when there are several wpview blocks in the editor and the user selects one after the other. [39910] #38849
  • Prevent the inline toolbar from appearing on partially selected wpview nodes. This can happen when HTML is initially loaded in the editor and wpview is the first node, or sometimes on repeatedly pasting the same wpview. [39904] #38849
  • When inserting a wpview, place the caret after is so the user can continue typing without interruption. [39903] #39337
  • Improve removal of spaces from empty paragraphs when loading HTML in the editor. [39902] #39437



  • Introduce signup_site_meta and signup_user_meta for filtering signup metadata in wpmu_signup_blog() and wpmu_signup_user(), respectively. [39920] #39223
  • User Query: Cast $user_total as an int. [39915] #39297
  • I18N: Reference correct placeholder in a translator comment added in [30333]. [39908] #30264
  • Display the name of user being edited on Edit User screen. [39907] #28182
  • Docs: Make $meta parameter description in multisite signup and registration functions more consistent. [39887] #38781
  • In wpmu_signup_blog() and wpmu_signup_user(), pass unserialized signup meta data to after_signup_site and after_signup_user filters introduced in [34112], to match the documented value. [39886] #38781


  • In unregister_sidebar(), rename the $name parameter to $sidebar_id for consistency with is_registered_sidebar(). [39892] #35147
  • Add nonce for widget accessibility mode. [39760-39771] #23328

Thanks to @aaroncampbell, @afercia, @afzalmultani, @Ankit K Gupta, @azaozz, @barryceelen, @ccprog, @dd32, @diddledan, @DrewAPicture, @dspilka, @F J Kaiser, @gitlost, @iandunn, @iseulde, @ixkaito, @jackreichert, @jblz, @jeremyfelt, @jnylen0, @joemcgill, @johnjamesjacoby, @kuck1u, @MaximeCulea, @Mista-Flo, @netweb, @ocean90, @pavelevap, @pbearne, @pento, @peterwilsoncc, @Presskopp, @rachelbaker, @raggedrobins, @rmccue, @runciters, @seanchayes, @SergeyBiryukov, @Soean, @swissspidy, @theMikeD, @tmatsuur, @vortfu, and @wpsmith for their contributions!

#4-8, #week-in-core

Improving the REST API users endpoint in multisite

One of the objectives for multisite is sorting how users are managed with the REST API. This was one of the agenda items for last week’s #core-multisite office hours and generated some good discussion. Here’s a wrap-up of the ideas and thoughts from that discussion.

Chat log in #core-multisite

Attendees: @iamfriendly, @johnjamesjacoby, @nerrad, @florian-tiar, @mikelking, @earnjam, @jeremyfelt

Users in multisite exist globally and are shared among sites on one or more networks. Users are associated with sites in the user meta table with a wp_#_capabilities key.

The current state of the wp-json/wp/v2/users endpoint for multisite is:

  • A POST request for a new global user to the main site creates the user and associates them with the main site only.
  • A POST request for a new global user to a sub site creates the user and associates them with the sub site only.
  • A POST request for an existing global user results in an error.
  • A PUT request for an existing global user to a sub site updates the user’s meta with a capability for that sub site.
  • A DELETE request on multisite is invalid and results in an error. See #38962.

It is not possible to remove a user from an individual site or to delete the user from the network.

Previous tickets: #38526, #39155, #38962, #39000

The following are a few thoughts expressed separately from the above summary.

  • The right way to associate existing objects over the REST API is with a PUT request.
  • The right way to disassociate existing objects is with a PUT request.
  • Linked previous discussion – “Deleting an item should always delete an item
  • We already have functions like remove_user_from_blog() and add_user_to_blog() available to us.
  • Does “add” invite or literally add? This can probably be included as data in the PUT request.
  • What happens if an API client is built for single site and then that site gets switched to multisite?
  • Handling bulk actions on an endpoint would be nice. (e.g. Add a user to multiple sites) No endpoint has implemented batch handling yet though.

Initial tasks:

  • It should be possible to remove a user from a site with a PUT request to the wp-json/wp/v2/users/# endpoint.
  • It should be possible to delete a global user with a DELETE request to the wp-json/wp/v2/users/# endpoint once all sites have been disassociated.

New tickets will be created soon for these tasks. Please leave any initial feedback in the comments on this post covering the assumptions and conclusions made above. There will be another round of discussion during tomorrow’s #core-multisite office hours at Tuesday 17:00 UTC.

/cc @rmccue and @kadamwhite

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

Multisite Office Hours Recap (December 13, 2016)

Multisite office hours are held every Tuesday at 17:00 UTC in #core-multisite. The next will be Tuesday 17:00 UTC.

The weekly agenda was to discuss long-term goals for multisite and prioritize tickets to work on related to one of the three new focuses, particularly the REST API.

Today’s chat log

Attendees: @iamfriendly, @mista-flo, @johnjamesjacoby, @loreleiaurora, @johnbillion, @jeremyfelt, @flixos90

Chat Summary:

  • @jeremyfelt, @flixos90, @johnjamesjacoby, and @johnbillion sat down for a chat at WCUS to discuss multisite topics and possible future focuses. @jeremyfelt shared his notes from that session. Items of particular interest in today’s chat were:
    • Identify statistics for multisite usage, size of multisites: Possibly sending more general multisite-related metrics during core updates could be helpful and should be further discussed. In addition to whether multisite is enabled and the count of sites (on the main network) it could be helpful for future decisions to know how many sites there are in total, how many networks exist and whether user / site registration is open or not.
    • Implementation of network user roles: A ticket is in place at #39174. @flixos90 requested feedback: Everyone interested is asked to read through the ticket description and provide an elaborate response with how they think network roles should work. Then a discussion based on these approaches can start.
    • Network administrators should be able to enable themes on the site level: It is currently not very convenient for a network administrator to switch back to the network admin to enable a theme when currently working within the site admin.
    • Disable plugins per site in the network admin: Sometimes not all plugins should be visible on all networks or all sites, which is currently not possible. However, even for a disabled theme a network administrator should still be able to “silently” activate it on a site. Plugins would need to be enabled by default, so it would be the opposite way of how themes are currently handled. This also ensures there are no concerns with backward-compatibility. UI-wise an improved flow should be investigated instead of simply pursuing a similar approach to how enabling themes works: Having all the functionality inside the Network > Plugins screen would be helpful, with row and bulk actions for “Network Disable” as well as “Disable for Site…” with the latter having some kind of popover with an autocomplete field for sites. A related ticket to take into account for the implementation is #38652 which @johnbillion opened to introduce singular capabilities for managing plugins.
    • Whichever flow is agreed on for disabling plugins per site or network, once this functionality is implemented, it will probably make sense to “back-port” the behavior to improve the existing theme and maybe even user handling in a multisite.
  • At this point, the highest priority is multisite support for the REST API.
    • The users endpoint should be improved, particularly the implementation of DELETE for a user on a multisite as well as removing a user from a site or setting their capabilities per site via PUT (see #39000 and #38962 for related tickets).
    • A sites endpoint should be added.
    • A networks endpoint is not as important and should for now only live in a standalone plugin if there is interest to implement it.
  • A general question raised was how No-JS fallbacks for REST API functionality in the admin should be handled. Should JavaScript become a requirement to use such new functionality or should the REST API only be used to improve existing PHP-only features? These questions should be discussed in a broader scope than just multisite since they affect all of WP Admin.
  • Possible usage for a REST API sites endpoint:
    • Replacing “My Sites” in the toolbar with a menu that doesn’t load until needed and pulls all sites from the API.
    • The possible autocomplete field for disabling plugins for a specific site (see above) could pull sites from the API.
  • @mista-flo brought up #13743 and asked for feedback. Everyone in the chat agreed that the ability to set a default theme for a network would be a valuable enhancement over the existing constant. For the approach, introducing a new row action “Set default theme” the Network > Themes list table was suggested, alongside an indicator “Default Theme” in that same table. This is an enhancement that can be worked on beside the other important REST API features.
  • A Google document was opened a while ago to gather input for a future multisite roadmap, as a follow-up to 2013’s post. @jeremyfelt highlighted that this document should continue to move forward in order to hopefully be able to publish an actual roadmap in early January.

#4-8, #multisite, #network-sites