Dev Chat Summary: October 18th (4.9 week 12)

This post summarizes the dev chat meeting from October 18th (Slack archive).

4.9 schedule and priorities review

  • Down to 54 tickets in the 4.9 milestone, aiming to get to 40 in time for Beta 3
  • Beta 3 build process will begin around Wednesday, October 18th 20:00 PDT / Thursday, October 19th 03:00 UTC
  • Starting next week, we’ll have 2x weekly bug scrubs to get to launch
  • Note the critical bug in Safari that breaks the new theme browsing/installation experience in the Customizer; please help on this if you're familiar with Safari
  • Integration issues with Shiny Updates and the new theme installation experience in the Customizer (see: #42184). In particular, the FTP credentials modal needs work for when it gets dismissed.

Dev Notes

General announcements

  • @mnelson4: #38583 could use feedback, ideally from from REST API component maintainers

#4-9, #core, #core-customize, #core-restapi, #dev-chat, #safari, #shiny-updates, #summary

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

Account Security Improvements in WordPress 4.9

A few account security enhancements have gone into WordPress 4.9. The intention is to make it more difficult for an attacker to take over a user account or a site by changing the email address associated with the user or the site, and also to reduce the chance of a mistaken or erroneous change causing you to get locked out.

  • In order to change your user account email address, the site admin email address, or the network admin email address on Multisite, a link now needs to be clicked in a confirmation email that gets sent to the new email address. This behaviour has existed for years on sites within a Multisite network — the functionality has now been ported to single site installations too. See #16470, #39118, and #39119.
  • The old site admin email address now gets notified of a change to the address (this includes the network admin email address on Multisite too). See #39117.
  • The email that’s sent to a user’s old email address when their email address is changed now includes the new email address. See #39112.

#4-9, #dev-notes

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

Dev Chat Agenda for October 11th (4.9 week 11)

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

  • 4.9 schedule and priorities review
  • 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

What’s new in Gutenberg? (October 10th)

With this release Gutenberg allows you to make edits and tweaks to the HTML of individual blocks, without having to hunt for the relevant code in the full document view.

 

1.4 🐼

Other changes

Feedback form

In 1.3 a feedback form was added to the Gutenberg sidebar menu. In the past week there have been 12 responses from it. Out of that, 4 bugs have been reported and 2 enhancements proposed.

#core-editor, #editor, #gutenberg

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