Multisite Focused Changes in 4.9

Here’s an overview of the developer facing changes made in multisite for the 4.9 cycle. If you’re interested in more detail, checkout the full list of tickets.

clean_blog_cache() replaces refresh_blog_details()

Since 3.5, refresh_blog_details(), which accepts a site ID, has been a wrapper of the clean_blog_cache() function, which requires a site object.

In WordPress 4.9, clean_blog_cache() has been adjusted to also accept a site ID and to invalidate caches for a deleted site in the same way. From now on clean_blog_cache() should be used instead of refresh_blog_details() which will be deprecated in a future release.

More importantly, the refresh_blog_details action has been deprecated in favor of the clean_site_cache action. See #40201.

New function get_main_site_id()

The WP_Network class has historically contained a $blog_id property indicating the ID of the main site of that network. However, since this property was never part of the wp_site database table, it is set manually in the multisite bootstrapping process. This results in it only being set for the current network. For any other network, code like get_network( $id )->blog_id would return 0.

The new get_main_site_id() function introduced in 4.9 provides the site ID of any network in an easy way. The function accepts an optional $network_id parameter, which defaults to the current network. Furthermore the magic property logic in WP_Network has been adjusted so that the $blog_id property (and its magic $site_id equivalent) is automatically set when requested. This ensures get_network( $id )->blog_id will always return a meaningful value. See #29684.

Refactored user capability and role switching

Switching the available roles and the current user’s capabilities no longer happens in switch_to_blog() and restore_current_blog(). Instead it has been moved to a new function, wp_switch_roles_and_user(), which is hooked into the site switching process. This provides a performance improvement by temporarily unhooking the function in cases where roles and capabilities do not need to be switched.

In addition, the available user roles are now correctly switched when switching sites, with refactored behavior in the WP_User and WP_Roles classes making this possible. These changes are more closely explained in the 4.9 post about role and capability improvements. For related tickets, see #36961 and #38645.

Site administrators can edit user roles through the REST API

While site administrators cannot edit user details in multisite, they are able to modify a user’s roles. In WordPress 4.9 this can now be achieved through the REST API by making a request such as PUT wp/v2/users/<id> and passing only the roles argument in the request body. No other arguments must be given as those would require the current user to have network administrator capabilities. See #40263.

Other Notes

  • The new can_add_user_to_blog filter can be used to prevent a user from adding specific users to a site or with a specific role. See #41101.
  • The old site network admin email address gets notified of a change to the address. See related security improvements for 4.9 and #39117.

#4-9, #dev-notes, #multisite, #networks-sites

Improvements for roles and capabilities in 4.9

Here is an overview of the developer facing changes focused on user roles and capabilities for the 4.9 cycle. If you’re interested in more detail, checkout the full list of tickets.

New Capabilities

Activating and deactivating plugins

It is now possible to manage capabilities for activating and deactivating plugins more granularly through the following new capabilities:

  • activate_plugin checks whether a user can activate a specific plugin. When checking the capability, it gets passed the plugin file (such as current_user_can( 'activate_plugin', 'my-plugin/my-plugin.php' )).
  • deactivate_plugin works similar to activate_plugin, but checks whether a user can deactivate a specific plugin as the name indicates.
  • deactivate_plugins allows to check whether a user can generally deactivate plugins.

By default, all of the above capabilities map to the existing primitive capability activate_plugins, so there is no change in behavior by default. However they make it possible to customize the behavior, for example to prevent specific users from activating or deactivating specific plugins. See #38652 for background discussion.

Installing and updating language files

The other group of new meta capabilities deals with installing and updating language files / translations:

  • install_languages checks whether a user can install new language files.
  • update_languages checks whether a user can apply language file updates.

By default, the capabilities are granted to a user when they have at least one of the existing update_core, install_plugins or install_themes capabilities. In addition, if wp_can_install_language_pack() returns false, the capability checks will return false as well. Again there is no change in behavior, but these capabilities allow customizing permissions more granularly, for example to not allow any updates other than language file updates. See #39677 for background discussion.

Hardening security against prohibited actions

When going through the map_meta_cap() function, several capabilities end up mapping to a value of do_not_allow, which is not an actual capability that should be used, but rather indicate that a user should under no circumstances be allowed to perform the respective action. However, it has historically been possible to manually grant users do_not_allow as an actual capability, which is a bad practice and would cause unexpected behavior. As of 4.9, it is no longer possible to do that. See #41059 for background discussion.

Refactored user capability and role switching in multisite

In multisite, switching the available roles and the current user’s capabilities no longer happens in switch_to_blog() and restore_current_blog(), instead it has been moved to a new function wp_switch_roles_and_user() which is hooked into the site switching process. This allows to improve performance by temporarily unhooking the function in cases where roles and capabilities do not need to be switched.

Furthermore the logic for both switching user capabilities in WP_User and switching available roles in WP_Roles has been refactored to work in a similar manner and provide more granular methods:

  • The WP_User::for_blog() and WP_User::_init_caps() methods have been deprecated in favor of WP_User::for_site().
  • WP_Roles::_init() has been deprecated in favor of WP_Roles::for_site().
  • Both WP_User and WP_Roles now provide a get_site_id() method to retrieve the ID for which the user’s capabilities/available roles respectively are currently initialized.

All these changes heavily benefit the process of switching sites, particularly by fixing a bug where available roles were not switched correctly prior. See #36961 and #38645 for background discussion.

Having a clean foundation now, several areas now deal with the available roles correctly when in a switched state. See #42013, #42014 and #42015 for the individual tickets.

 

#4-9, #dev-notes

Multisite Recap for the week of October 9th

Office Hours Recap

The agenda for this office hours meeting was to review 4.9 bug and task tickets that still need to be finished and merged within Beta, particularly continuing from where the ticket scrub meeting stopped.

The meeting’s chat log

Attendees: @earnjam, @flixos90, @jeremyfelt, @jjj, @johnbillion, @josheby, @spacedmonkey, @stevenkword

Chat Summary:

  • #41936: It was decided that the new filter pre_get_main_site_id should not actually set the WP_Network::$blog_id property when used and only override the return value when accessing it, as it could otherwise have unexpected consequences if a hook set for it was (temporarily) removed. The latest patch had one issue where a variable had not been correctly renamed after moving the code from the function to the class method. It was furthermore discussed how verbose and strict casting the value returned by a filter should be. It was decided to only return the filter value if 0 < (int) $value. Both issues have since been fixed in the latest patch.
  • #38570 and #41652: @sergey is taking care of these i18n tickets.
  • #41789: @johnbillion will provide feedback.
  • As there is now a 5.0 milestone on Trac, the priority tickets that were previously flagged with “Future Release” and “early” are now being moved into the actual milestone.
  • #40364: @flixos90 asked for feedback for this rather complex ticket, as it should preferably get ready early in the 5.0 cycle. That ticket should be discussed in detail in one of the next few weeks, once the multisite work for 4.9 has wrapped up.

Next meeting

The next office hours will take place on October 17th, 2017, 16:00 UTC. Its agenda will be to continue discussing 4.9 tickets and the dev-note for the Networks & Sites component.

Ticket Scrub Recap

The agenda for this ticket scrub was to review 4.9 bug and task tickets that still need to be finished and merged within Beta, similar to the office hours meeting agenda this week (see above).

The meeting’s chat log

Attendees: @afercia, @flixos90, @jeremyfelt, @jjj, @paaljoachim, @spacedmonkey

Chat Summary:

  • #41936: It was decided that moving the logic that is currently in get_main_site_id() is okay to be moved to WP_Network:get_main_site_id(), since that data is very specific to each individual network. It must furthermore be ensured that all values are properly typecast into the expected type (WP_Network::$blog_id is a string, WP_Network::$site_id is an integer and WP_Network::get_main_site_id() should always return an integer). Minor tweaks suggested were returning get_current_blog_id() instead of a hardcoded value of 1 in get_main_site_id() for non-multisite environments and using an internal variable for the cache key used. @spacedmonkey and @flixos90 will make sure this gets ready.
  • #42093: @jeremyfelt has been working on providing an easy way to run unit tests for a subdomain install. This ticket is currently a task scheduled for 4.9, but may as well be punted to 5.0 in case it does not get ready in time.
  • #39419: It was agreed on that the doc block for the globals should indicate replacements to use for those that are deprecated. @jeremyfelt has since updated the patch. It is still being considered whether globals such as $table_prefix, which are used there, but not actually set up there initially should be listed as well.
  • #41789: It was briefly discussed how to be most precise about the documentation of the get_sites() (and related WP_Site_Query method) return value, without making the description overly complex. @jeremyfelt added the final idea as a comment on the ticket and is now waiting for feedback. It was also mentioned that documentation for the other query classes should probably be changed in a similar way, however the ticket for now should only deal with sites and networks.

Next meeting

The next ticket scrub will take place on October 16th, 2017, 17:00 UTC. Its agenda will be to continue discussing 4.9 tickets, particularly the issue that came up with #40228.

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

Remaining Bug Scrubs for 4.9

The following bug scrubs have been planned for remainder of the 4.9 release cycle, focused on tickets remaining in the milestone, and will take place in #core:

As a refresher, here's a post from the 4.7 release cycle answering questions about bug scrubs.

Dev Chat Summary: October 11th (4.9 week 11)

This post summarizes the dev chat meeting from October 11th (agendaSlack archive).

4.9 schedule and priorities review

  • Today is the Beta 2 deadline
  • Beta 2 build process will begin around Wednesday, October 11th 20:00 PDT / Thursday, October 12th 03:00 UTC
  • Next on the 4.9 release schedule will be Beta 3 next week on Wednesday, October 18th
  • Alpha/Beta/RC Forum has been quiet, excepting one that turned into a beta2 fix
  • Fix for PHP file editor came in via Twitter
  • Testing ideally focused on:
    • Remapping of nav menus and widgets when switching themes (see #39693 and #39692)
    • The updates the theme/plugin code editors
    • Scheduling and drafting in the Customizer
    • Locking in the Customizer (like post locking, but for your site changes)
    • Theme browsing and installation in Customizer
    • Revamped nav menu creation flow
    • Video and gallery widgets, plus Text widget with embeds
    • Browser testing, especially mobile + IE
  • 16 tickets still need patches
  • Would appreciate help reviewing patches and committing from committers over next two weeks

Dev Notes

  • 24 tickets tagged with needs-dev-note
  • Dev Notes were due with Beta 1, so we're behind on those
  • Please aim to publish those by this time next week so we can compile them into the Field Guide before Release Candidate

General announcements

  • @paaljoachim: Has there been any discussion about Twenty Eighteen theme?
    • No plans as of now for Twenty Eighteen, likely not enough time to start and finish by end of the year anyway
  • @presskopp: looking for an answer on my question on #42131
    • Recommendation to check with the Widget component maintainers who may otherwise be focused on Customize-related defects with 4.9

#4-9, #core, #core-customize, #dev-chat, #media-widgets, #summary

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

Media meeting recap – October 5, 2017

Overview

This post is a summary of the latest weekly Media component meeting, which took place in the #core-media Slack channel, on Thursday, October 5, 2017, 18:00 UTC. The purpose of these meetings are to move priority tasks forward, provide feedback on issues of interest, and review media focused tickets on Trac.

Attendees:
@joemcgill, @karmatosed, @blobfolio, @mikeschroder.

Transcript: Read on Slack

4.9 beta 1 review

First of all, I want to thank everyone who helped work on tickets the past few weeks. We were able to ship all of the enhancements that were still on the milestone before the deadline 🙌🏻.

Here are the relevant tickets with commits from this week:

  • #33981 – Default Captions Should Use max-width
  • #21819 – Reduce duplicated custom header crops int he Customizer
  • #35218 – Parse the creation date out of uploaded videos
  • #41629 – Default to “custom URL” in the image widget
  • #40894 – Use Webpack instead of Browserify for build process

Please continue testing these and provide feedback as you notice anything.

Priority tickets for the coming week (beta 2)

There are two MEJS issues, both which are close to commit:

  • #41787 – Media: JS error when removing a video/audio sourced
  • #42071 – MediaElement upgrade causing JS errors when certain languages are in use

Other high priority tickets for this week:

  • #21819 – Use an image size for custom headers instead of duplicating an attachment – @joemcgill to continue iterating here, feedback and testing welcome.
  • #37750 – Cropping custom logo should preserve attachment properties – This is closely related to #21819.
  • #41973 – HTTP Error when uploading images on PHP 7.1.9 (needs confirmation) – @mikeschroder tested and left a comment. Seems like a configuration issue but we’ll continue tracking throughout beta to see if we can help resolve on our end.
  • #40175 – Upload Validation / MIME Handling – @blobfolio refreshed the patch, which needs further testing and review.

Tickets with no owner in the 4.9 milestone:

  • #40921 – Inconsistent Handling of mp4 by Audio Widget – @toddhalfpenny since volunteered to continue working on it, just needs review.
  • #41844 – Media: audio players overflow playlist containers – @celloexpressions and @melchoyce have been working on this one.

Our next meeting is scheduled for Thursday, October 12, 2017, 18:00 UTC and will be lead by @karmatosed.

#core-media, #media

Dev Chat Summary: October 4th (4.9 week 10)

This post summarizes the dev chat meeting from October 4th (agendaSlack archive).

4.9 schedule

  • Today is the Beta 1 deadline for enhancements and feature requests. All tickets have been scrubbed as of earlier today, any that are still open when the Beta 1 build process begins later today will be punted to Future Release.
  • Next on the 4.9 release schedule will be Beta 2 on Wednesday, October 11th.
  • 30 enhancements and features still in the milestone
  • Beta 1 build process will begin around Wednesday, October 4th 20:00 PDT / Thursday, October 5th 03:00 UTC

Gutenberg block data storage

  • Want to start thinking about and discussing how block data is stored. We currently (specially after allowing meta attributes) have a lot of ways to store block data, with different tradeoffs. It’s going to be important to communicate when each is appropriate.
  • This will come through examples and documentation, but generally such knowledge has also spread by core contributors doing talks and blog posts, etc.
  • As people start to look at creating blocks, there are various ways to specify attributes, and different ways things can be saved (static blocks, dynamic blocks, etc). A lot of the reason people used custom fields or meta attrs will be different as blocks allow individual attributes that are still part of the content.
  • If you have input to share on that, please join in #core-editor and their weekly meetings.

REST API Handbook

  • They are moving / have moved the REST API Handbook content to GitHub.
  • Once it’s deployed, the REST API handbook’s content will be managed in GitHub.

General announcements

  • @rskansing: I want to give a thanks to the security team for always being very nice and polite in regards to my many queries and questions

#4-9, #core, #core-restapi, #dev-chat, #gutenberg, #security, #summary

What’s new in Gutenberg (4th October)

1.3 🦍:

Other changes:

We welcome all your feedback and contributions on the project repository, or ping us in #core-editor. Follow the “gutenberg” tag for past updates.

#core-editor, #editor, #gutenberg

Dev Chat Agenda for October 4th (4.9 week 10)

This is the agenda for the weekly dev meeting on October 4, 2017 at 20:00 UTC / October 4, 2017 at 20:00 UTC:

  • 4.9 schedule
    • Beta 1 deadline for Enhancements and feature requests today
  • Gutenberg block data storage
  • REST API Handbook
  • General announcements

If you have anything to propose to add to the agenda or specific items related to the above, please leave a comment below. See you there!

#4-9, #agenda, #dev-chat