Dev Chat Summary: November 15th (4.9 week 16)

This post summarizes the dev chat meeting from November 15th (agenda, Slack archive).

4.9 schedule + release timing

  • 4.9 release was delayed from yesterday (Tuesday, November 14th) to today (Wednesday, November 15th)
  • An updated 4.9 build went out earlier today, we still have to rebuild tinymce.min.js, but otherwise please test!
  • @afercia disagrees with patching last minute serious bugs without proper, broad, testing but deferred to decision by release leads
  • 4.9 release scheduled for later today (Wednesday, November 15th) at 3pm PST / 23:00 UTC
  • [Editor note: 4.9 released successfully! 🚀]
  • We’ll discuss post-4.9 / pre-5.0 plans later once we’ve had a chance to gather broader feedback on 4.9.
  • There is currently no timeline or plan for 4.9.x, but there are tickets currently slotted as 4.9.1 in Trac.

Meeting time changes

Gutenberg update

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

Dev Chat Summary: November 8th (4.9 week 15)

This post summarizes the dev chat meeting from November 8th (agenda, Slack archive).

4.9 schedule

  • 4.9 RC2 went out this week
  • 4.9 release scheduled for Tuesday, November 14th at 3pm PST / 23:00 UTC
  • Decision against adding any pointers in the admin interface, changes should be discoverable without them
  • @obenland to update the Credits API on Tuesday
  • @jbpaul17 to make updates to 4.9 codex page
  • @melchoyce to generate Press Kit including screenshots and videos

Meeting time changes

Gutenberg update

General announcements

  • @jdgrimes: looking for additional help, feedback, and decisions on #41593
    • I got started on this building a PHPCS sniff for the WordPress-Coding-Standards
    • The sniff would check all calls to functions that expect slashed data, and ensure that the data passed to them was actually slashed
    • I have a list of all the functions that expect slashed data, ticket is to get all of these documented
    • There may be some places where we need to decide whether we want to keep expecting slashed data or not

#4-9, #core, #dev-chat, #summary

Dev Chat Summary: November 1st (4.9 week 14)

This post summarizes the dev chat meeting from November 1st (Slack archive).

4.8.3 Release

  • We've seen a few reports, one issue with meta queries in WP_Query
  • No reports of linebreaks being removed after updating to 4.8.3
  • No issues reported through plugins (just some ACF/query oddities)

4.9 schedule

  • 4.9 RC1 went out on Monday
  • No feedback on RC1 testing or other issues to discuss, but please keep testing!
  • There are three tickets remaining with needs-dev-note, all relate to work I believe @westonruter is working through
  • @jbpaul17: working to pull together the Field Guide but could use some help writing summaries for the dev notes and collecting details for the New Action Hooks, New Filter Hooks, Modified Filter Hooks, and External Library Updates sections.
  • @jbpau17: Any component maintainers that want to highlight other tickets that weren’t significant enough to warrant dev notes, please send those Trac numbers to me ASAP
  • Aiming to publish the Field Guide by the end of the week, so any help before then would be wonderfully appreciated. Please reach out to @jbpaul17 (@jeffpaul on Slack) if you have availability… thanks!

General announcements

  • @davidakennedy: I should have #42090 committed today. Working on figuring out the updated POT files now. Will ping another committer to review before commit.

#4-8-3, #4-9, #core, #dev-chat, #summary

Dev Chat Summary: October 25th (4.9 week 13)

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

4.9 schedule

  • Beta 4 dropped late last night / early this morning, please do help test. RC is scheduled to go out on Monday, October 30th and that entails soft string freeze.
  • For all @committers, please let @melchoyce @westonruter know if you are able to help with commits during RC as we’ll need two committers to approve a patch before merging.
  • Bug Scrubs are scheduled on Monday’s and Thursday’s. If you have availability to help run a scrub, please let @jbpau17 know. Any help would be greatly appreciated, thanks!
  • Currently nine tickets that show as needs-dev-note
  • Three Dev Notes coming from @westonruter and one from @rafa8626 (#39686); all could use proofreading
  • If anyone can help draft the Field Guide, please let @jbpaul17 know especially for things around New Action Hooks, New Filter Hooks, Modified Filter Hooks, and External Library Updates.
  • If anyone can help populating the “Developer Happiness” section of the About page, please let @melchoyce know or add notes to #42087

Editor / Gutenberg update

  • Gutenberg v1.5 includes metabox support and likely has advanced cases where the plugin will benefit from feedback and iteration.
  • You can report via GitHub, the feedback form within the Gutenberg plugin, or in #core-editor.

General announcements

  • @johnbillion: The last PHP 7.2 issue, #41526, needs some eyes and can still make it into 4.9 if another patch comes along. The original patch causes some warnings.
  • @paaljoachim: looking for comments on #42324

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

Improvements in REST API request parameter regular expressions

With WordPress 4.9, a bug has been fixed which would cause unexpected numeric results to be included in the parsed URL parameters for a REST API request. Prior to this change, calling WP_REST_Request::get_params() for a request like /wp/v2/users/(?P<id>[\d]+) with an ID of 10 would return array( 'id' => 10, 1 => '10' ), where the latter numeric key is unnecessary and a result of PCRE matching against a named subpattern (see preg_match() documentation). The fix ensures that the above request now only returns array( 'id' => 10 ) instead. This helps for example to verify that a request does not include more than a few specific parameters.

The WP REST API docs have always been using named URL parameters, using regular (numeric) matches was never recommended. With this bug fix in place, using named parameters is now effectively required, for example /my-namespace/my-endpoint/(?P<numeric_param>[\d]+) must be used instead of /my-namespace/my-endpoint/(\d+). For background discussion on these changes, see #40704.

#4-9, #dev-notes, #rest-api

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

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

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