Miscellaneous Developer Focused Changes in 5.1

In WordPress 5.1, a handful of small developer-focused changes were made that deserve to be called out. Let’s take a look!

File Path Value For WP_DEBUG_LOG

WP_DEBUG_LOG is a constant that tells WordPress to enable or disable error logging. Its default value is false (no error logging). But, if it’s defined as true (or 1) in the wp-config.php file, site errors will be logged in the wp-content/debug.log file.

Starting in WordPress 5.1, WP_DEBUG_LOG will also accept a file path as a value allowing a custom error log to be defined. For example:

define( 'WP_DEBUG_LOG', '/srv/path/to/custom/log/location/errors.log' );

Here are a few things to keep in mind:

  • The directory must already exist and be writable by the web server’s user.
  • The file does not need to exist. It will be created once the first error occurs as long as the previous condition is met.

Reminder: Any values set to WP_DEBUG_LOG and WP_DEBUG_DISPLAY will be ignored unless WP_DEBUG is set to true.

For more information, see #18391.

Test Suite: New Test Config File Constant

When running PHPUnit tests, the WordPress test suite requires a wp-tests-config.php file to be present in order to run correctly. This file provides information similar to that provided by the wp-config.php file. This includes database information, site domain and title, etc. (see the wp-tests-config-sample.php file for more information). However, the test suite bootstrap file requires this file to be in one of two locations: the test directory (tests/phpunit), or the root of the develop repository.

Starting in WordPress 5.1, the WP_TESTS_CONFIG_FILE_PATH constant can now be added to the phpunit.xml configuration file to define a custom location for the wp-tests-config.php file.

<phpunit ...
	<php>
		<const name="WP_TESTS_CONFIG_FILE_PATH" value="/path/to/wp-tests-config.php" />
	</php>
</phpunit>

For more information, see #39734.

New Plugin Action Hooks

In WordPress Core today, the plugins_loaded, network_plugins_loaded, and mu_plugins_loaded action hooks exist, but these hooks are only run after all plugins of their respective types have been loaded. There is no easy way to execute arbitrary code between each plugin being loaded or only after plugin X is loaded.

This makes it difficult for developers to conduct performance monitoring and debugging during this stage of the loading process. In WordPress 5.1, the following action hooks will be added:

  • plugin_loaded
  • network_plugin_loaded
  • mu_plugin_loaded

These hooks will fire after every plugin is loaded. Each action hook will pass one argument, the full path of the main plugin file.

Because these hooks are fired after every individual plugin is loaded, they are not recommended as a replacement for plugins_loaded. Using them in this manner will cause issues with performance.

For more information, see #41346.

Short Circuit Filter for wp_unique_post_slug()

When a post is created or updated, wp_unique_post_slug() is used to ensure that the post slug (post_name field) is unique to that post. By default, the function will add a numeric suffix to the desired post_name value and increment until a unique value is created (desired-slug-2, desired-slug-3, etc.).

In some scenarios (when post titles are the same and no post_name values are provided, for example), this can result in a performance bottleneck because a new query is performed every time the suffix is incremented until a unique value is created.

To help with this scenario, the pre_wp_unique_post_slug filter has been added in WordPress 5.1. If a non-null value is returned, the function will return that value and skip the default logic in the function. The new filter also opens the door for a handful of other use cases, such as always replacing certain terms in post names (changing wp to wordpress, for example).

For more information, see #21112.

Additional Developer Goodies

  • wp_debug_backtrace_summary() (which returns a list of functions called to get to the current point in the code) will now correctly capture hook names for do_action_ref_array() and apply_filters_ref_array() calls (see #43488). Previously, only do_action() and apply_filters() were captured.
  • $wpdb->queries logs the elapsed time for each query but lacks the starting time. This has been added in 5.1 (see #43315).
  • The WP_Error class now has a has_errors() method, which returns a boolean value indicating if an instance contains errors. This adds consistency to code that has previously checked for errors in a variety of ways, such as if ( $error->get_error_code() ) and if ( empty( $error->errors ) ) (see #42742).
  • A large number of inline documentation updates have been made to ensure accuracy proper formatting.

#5-1, #dev-notes

PHP Site Health Mechanisms in 5.1

Update: A few critical naming changes have been made regarding the fatal error protection since the post was originally published. Most importantly, the drop-in to override the new shutdown handler is now called fatal-error-handler.php, and the class to override is called WP_Fatal_Error_Handler. Furthermore, a new WP_DISABLE_FATAL_ERROR_HANDLER constant allows entirely disabling the feature via wp-config.php. The rest of the post is also updated to use these new terms, however you might need to update your code if you built anything based on the previous information. For a history of what exactly has changed since the original post date, please refer to the umbrella ticket #44458.


WordPress 5.1 will start showing notices to administrators of sites that run on long outdated PHP versions. This part of the Servehappy and more globally Site Health projects paves the way to a more secure and performant web and, more specifically to WordPress, to a bump of the minimum required PHP version.

The current threshold for which PHP versions to display the notice will be anything below 5.6. While the lowest PHP version still receiving security updates is currently 7.1, the idea is to not go all the way there at the beginning to limit the support load. PHP 5.6 is the intended version to bump WordPress requirements to, and from then the threshold for the PHP notice will increase granularly, with the goal to over time catch up with the actual PHP version progress. The threshold is managed via a new Servehappy API endpoint on wordpress.org, so the version numbers can be modified independently of a WordPress release.

Warning about outdated PHP version in WordPress backend

The link from the button points to a new support page about updating PHP which briefly explains the problem and then dives into how to prepare for an update and perform it. The link URL in WordPress is a translatable string so that locales can provide their own versions of the page. In order for that process to be straightforward, the content is managed through a page template, with the translation strings thus being available in GlotPress (see https://meta.trac.wordpress.org/ticket/4004). Furthermore, the link can be adjusted via either an environment variable WP_UPDATE_PHP_URL intended for hosting providers or a filter wp_update_php_url for a more dynamic approach on the code level. Replacing the URL should happen in cases where a more specific guide to update PHP on the given environment exists. The hosting provider is the preferred source to set this, so plugins are recommended to honor this priority and not unconditionally override it. Furthermore, if the URL is changed in any way, the URL to the original WordPress resource is still maintained as an additional link, which you can see in the following screenshot:

Warning about outdated PHP version with custom URL and related annotation

For further background information on these changes, please refer to the respective tickets #41191 and #45686.

Fatal Error Protection

To help the process of recovering errors that result from updating the PHP version, a mechanism has been implemented to detect fatal errors and, in certain designated areas of WordPress, recover from them. While updating PHP is mostly fairly straightforward and popular plugins and themes are typically maintained well, not necessarily all extensions are compatible with the latest PHP versions yet. So unfortunately there might be cases where a plugin or theme causes the WordPress site to no longer be accessible after the PHP update by causing a fatal error.

With the so-called WSOD protection (white-screen-of-death protection), WordPress will recognize when a fatal error occurs and which plugin or theme is causing it. When accessing the admin backend, the respective extension will be paused, allowing users to still log in to their site so that they can (at least temporarily) fix the problem. Once the extension is known to be fixed, it can be resumed from the backend. While this does not necessarily make updating PHP easier, it lowers the burden of possibly running into the case where you are completely locked out of your site when you do not have access to the codebase.

Extensions are only paused in the admin backend and a few other areas while for example the frontend stays unaffected, and thus broken. Since it is impossible to predict which functionality the broken extension is responsible for, it would be dangerous to have it disabled in the frontend. It is more clear to a user accessing the site to see a message that it is currently not accessible rather than, without notice, no longer having access to a certain part of the key functionality. In the frontend, a message that the site is currently inaccessible will be displayed via a regular wp_die() call, with a link to the admin backend. Sites that would like to modify this output can use a new php-error.php drop-in that should send the necessary HTTP header as well as the output.

Default output in the frontend when WSOD protection detects has detected an error

Note that, while the primary reason for implementing the fatal error protection mechanism was making the process of updating PHP less “dangerous”, it is technically not tied to the update at all. In fact, it will be enabled permanently and discover fatal errors under any circumstances.

For sites that prefer to alter this behavior or sites that would like to omit the WSOD protection altogether, it is possible to add a new drop-in file fatal-error-handler.php. That file should declare a custom shutdown handler class for treating fatal errors that extends the default WP_Fatal_Error_Handler, and then return the instance of it to use. The default class’s functionality is split into distinct methods so that it is easy to reuse and override as granularly as necessary in a child class. The functionality can also be disabled entirely if that is preferred, via a new constant WP_DISABLE_FATAL_ERROR_HANDLER or, more dynamically, a corresponding wp_fatal_error_handler_enabled filter.

For further background information on these changes, please refer to #44458.

Honoring Plugin PHP Version Requirements

When browsing plugins to install, WordPress 5.1 will display a warning for those plugins that require a higher PHP version than the one currently active. While that screen previously already included such information about WordPress version compatibility, it now does the same for PHP. Furthermore, for both of these potential issues, WordPress will now enforce these requirements, disabling the button to install such plugins.

This is only a first step in enforcing version requirements of plugins and themes. In a future WordPress version, these restrictions will expand also to updating or activating plugins and eventually cover themes as well.

For further background information on these changes, please refer to #43986.

#5-1, #dev-notes, #servehappy

Reverting the Bulk Ticket Closing

Recently, a bulk modification was performed on Trac affecting 2,300+ tickets that had not seen any activity in 2 years or more. These tickets were closed and marked as wontfix. To read a more detailed breakdown, check out the previous post on the subject.

After discussing, it has been determined that the bulk action should be reverted, but only for tickets that have not had their status changed or otherwise confirmed via comments that closing is acceptable since the bulk closure. It can be safely assumed that closed tickets updated after the bulk edit have been appropriately groomed and should remain in their current state. A full list of tickets slated to be reopened can be found using this Trac query.

Tickets should only be closed if they have been individually evaluated and it is determined that they are either no longer relevant, have been fully and properly addressed, and any changes have been adequately communicated to the community.

These tickets will be reopened during the week following the 5.1 release (February 24-March 2) by @jeffpaul and myself (@desrosj). All reopened tickets will be placed in the Awaiting Review milestone so that they can be properly triaged by component maintainers and the Triage Team in the coming months.

#trac, #triage

New REST API Notice in 5.1

Edit: On January 14, 2019, the Good and Bad Practices section was added to show both correct and incorrect code examples.

Starting in WordPress 5.1, if register_rest_route() is not called on the rest_api_init action hook, a “doing it wrong” notice will be triggered. This notice is being added in an effort to encourage best practices when registering REST API endpoints.

First, let’s look at what happens when WordPress loads to set up the REST API and explore a few reasons why this pattern is beneficial.

REST API Bootstrap Process

WordPress does its best to ensure that the REST API is only loaded when a REST request is being performed. To do this, the rest_api_loaded() function is run on the parse_request action and checks for a value in the rest_route query argument. This argument is populated with a value when the Rewrite API matches a WordPress REST API URL. When a value is present, the rest_get_server() function is called to instantiate the WP_REST_Server class, store it for use across WordPress, and to run the rest_api_init action hook.

Performance

When register_rest_route() is called, it invokes rest_get_server() to retrieve the global WP_REST_Server instance created in the bootstrap process. But, if the instance has not been set up yet, it is instantiated then and the rest_api_init action hook is run. This means that every function added to the rest_api_init hook will fire at that time. This could result in a large performance hit.

For example, say register_rest_route() is called on the init action, or, just called in a theme’s functions.php file. The REST API server would be set up for every WordPress request, even those that are not actually aimed at the REST API.

Missing Endpoints

If register_rest_route() is called too early, it’s also possible that endpoints will go missing and never be registered. This happens when other plugins are not given the chance to register their rest_api_init hooks.

For example, say register_rest_route() is called directly in an mu-plugin file. This will cause the REST API to be set up before regular plugins are run, so their rest_api_init hooks will not be registered.

Good and Bad Practices

Let’s look at a few code examples and detail why they are good or bad.

Bad Practice

register_rest_route(
	'hello-world/v1',
	'/phrase',
	array(
		'method'   => 'GET',
		'callback' => 'myplugin_get_endpoint_phrase',
	)
);

In this example, register_rest_route() is called directly in a file without being attached to an action hook. This means the function will be called as soon as the file is loaded by WordPress. All of the potential issues detailed above are possible, and a _doing_it_wrong() notice will be triggered.

Good Practice

function myplugin_register_endpoints() {
	register_rest_route(
		'hello-world/v1',
		'/phrase',
		array(
			'method'   => 'GET',
			'callback' => 'myplugin_get_endpoint_phrase',
		)
	);
}
add_action( 'rest_api_init', `myplugin_register_endpoints` );

In this example, register_rest_route() is correctly placed inside of a function that is added to the rest_api_init action hook. It will only execute when the rest_api_init action hook is executed. The potential issues detailed above are avoided, and no _doing_it_wrong() notice is triggered.

Changes Required

Plugins and Themes

All plugins and themes should double check that their REST API endpoints are being registered correctly using the rest_api_init action hook. This best practice is also mentioned in the Routes and Endpoints section of the REST API Handbook. If this was a resource used when developing, chances are you won’t have to change anything!

Unit Tests

Because some unit tests require custom endpoints to exist, it is not uncommon for a test method to call register_rest_route() directly. If a test method calls the function before rest_api_init, a previously passing test method may now fail. This can be fixed in two ways.

The first way is to use rest_get_server() to create the WP_Rest_Server instance for your tests. Since rest_api_init is run within that function, this will prevent the notice. This approach can be seen in the Tests_REST_Server class. The wp_rest_server_class filter still allows you to replace the default WP_Rest_Server class with your own for testing purposes with this method.

The second way is to call do_action( 'rest_api_init' ); directly in your test method or setUp() method. This method is for scenarios where complete control is needed over the REST server setup process. This can approach can be seen in the Tests_REST_API class.

You can read more information about this change in the ticket on Trac.

#5-1, #dev-notes, #rest-api

What’s New in Gutenberg? (20th February)

More than 51 contributors participated in this release. It marks an important milestone for Phase 2, as it’s the end of the porting widgets to blocks project. Next releases will be focused on explorations around the Widgets screen.

Widgets 2 Blocks

This release also includes a big refactoring to the formatting buttons and the RichText component, allowing us to fix a significant number of issues and to improve the writing flow.

Core blocks (aside from the Classic block) are not using TinyMCE under the hood anymore. This change should not have any perceivable impact, as the APIs of the RichText component and the custom formats registration have not changed.

In addition, contributors have worked on a number of improvements to existing blocks and UI micro-animations.

Enhanced Menus

Click to activate embed blocks

5.1

Features

Enhancements

Bug Fixes

Various

Chore

Documentation

Mobile

Performance Benchmark

The following benchmark compares performance for a particularly sizeable post (~ 36000 words, ~ 1000 blocks) over the last releases. Such a large post isn’t representative of the average editing experience, but is adequate for spotting variations in performance.

Version Loading Time KeyPress event (typing)
Gutenberg 5.1.0 9.4 seconds 16.4ms
Gutenberg 5.0.0 10.4 seconds 16.4ms
Gutenberg 4.8 (WordPress 5.1) 13.6 seconds 158.2ms
Gutenberg 4.7 (WordPress 5.0) 15.1 seconds 203.5ms

👏 Kudos to all the contributors. Thank you.

#core-editor, #editor, #gutenberg

LIKE support for meta keys in 5.1

WordPress 5.1 introduces limited LIKEsupport for meta keys when using WP_Meta_Query. The new compare_key parameter (meta_compare_key as a top-level WP_Query query arg) accepts a value of LIKE in addition to the default =. See #42409 and [42768]. Here’s an example of how the new parameter is used:

$q = new WP_Query(
  array(
    'post_type'  => 'my_custom_post_type',
    'meta_query' => array(
      array(
        'compare_key' => 'LIKE',
        'key'         => 'foo',
      ),
    ),
  )
);

This will generate a query of the form ... AND meta_key LIKE '%foo%' ....

This enhancement follows from changes in WordPress 4.8.3 to the way that MySQL wildcard characters are handled when building queries. The changes in 4.8.3 broke compatibility for some plugins that passed wildcards into the key parameter of meta queries. The new compare_keyfeature in WP 5.1 is not a full replacement for the previous behavior, but it should allow for most use cases. See #43445 for discussion.

#5-1, #dev-notes, #query

Backwards Compatibility Breaks in 5.0.1

5.0.1 was just released to fix several security bugs. The Security team tried very hard to mitigate all of the vulnerabilities without any back-compat breaks, but unfortunately there were a few cases where that was not possible.

Security patches are backported to the 3.7 branch, so these BC breaks also apply to versions 4.9.9, 4.8.8, etc.

Form element no longer passes KSES

Prior to 5.0.1, the $allowedposttags array contained an entry for the <form> element and some of its attributes. Because of that, Contributors and Authors could use it in posts.

The element was removed in 5.0.1, except for situations where a plugin has explicitly registered input or select fields via the wp_kses_allowed_html filter. If a Contributor or Author includes <form> in their post, it will be removed when the post is saved. It will also be stripped from arbitrary content that plugins pass to wp_kses_post() or wp_kses_allowed_html( 'post' ).

If a plugin author wants to restore the original behavior, they will need to add form, input or select tags via wp_kses_allowed_html. Please exercise caution when doing so, because this could re-introduce a vulnerability. Make sure only trusted users are allowed to add <form> tags. 

meta_input, file, and GUID inputs are ignored

Prior to 5.0.1, $_POST requests for creating posts could contain values for meta_input, file, and guid. This is no longer true, and values passed for those fields will be ignored.

Plugins should not manually manipulate $_POST, but rather use the appropriate filters, and always validate/sanitize any data coming from an untrusted source.

MIME validation for uploaded files

Prior to 5.0.1, WordPress did not require uploaded files to pass MIME type verification, so files could be uploaded even if the contents didn’t match the file extension. For example, a binary file could be uploaded with a .jpg extension.

This is no longer the case, and the content of uploaded files must now match their extension. Most valid files should be unaffected, but there may be cases when a file needs to be renamed to its correct extension (e.g., an OpenOffice doc going from .pptx to .ppxs).

#5-0-1, #5-0, #dev-notes

JavaScript chat summary, February 12th, 2019

Below is a summary of the discussion from this week’s JavaScript chat (agenda, Slack Transcript)

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

“React As UI Runtime” Article

@nerrad shared “React As UI Runtime” article by Dan Abramov. Its good resource for folks who are familiar with React and want to deep dive into internal working. It will give you insight into the various aspect of React how things work and why they work in a certain way.

Custom ESLint Rules

Two new ESLint rules have been implemented:

Icon Package

The design team is exploring improvements for the Dashicons project and proposed the following:

  • The current workflow for adding icons and updating the font is not ideal and doesn’t scale for a big number of icons.
  • Gutenberg requires a big number of icons to avoid duplicates, it relies on SVGs instead of fonts and an option being explored is to take Material Icons as a basis and extend it with WordPress specific icon sets.

Some ideas were explored but final decision pending, until some better ideas and direction by the design team is finalized:

  • Exposing icons to global script handle though that could be huge to load.
  • @nosolosw suggested:
    • Getting some inspiration from GridIcons.
    • wp_enqueue_icon a function to declare the icons for use and make them available under wp.icons.* (for the ones enqueued)?
  • @youknowriad suggested:
    • Bundling all the icons as a separate package one big set to choose from.
    • Using the build process and tree shaking to include icons in use.
    • Getting inspiration from FeatherIcons.
    • Lazy loading icons if feasible.

Open floor

  • @welcher shared a resource he put together for various slot-fill and filter.
  • @gziolo suggested to include them in the official handbook.

#meeting-notes, #core-js, #javascript

WordPress 5.1 Field Guide

WordPress 5.1 is officially the best WordPress 2019 has seen yet! Users will see block editor improvements while developers will see PHP version upgrade notices and will be able to take advantage of 165 enhancements and features added.  Let’s look at the many improvements coming in 5.1…

Site Health 💻🏥

WordPress 5.1 includes portions of the Servehappy and Site Health projects. Notices will start being displayed to administrators of sites that run on long outdated PHP versions. WordPress will also start honoring plugin PHP version requirements.

Block Editor Goodies 🧱🏗️

The block editor continued its rapid iteration since WordPress 5.0 and now has version 4.8 of the Gutenberg plugin bundled with WordPress 5.1. Most significantly, this includes performance improvements within the editor, a Getting Started with JavaScript tutorial, improvements to the design guidelines to build blocks, and high-quality README files for the UI components.

Multisite Metadata 🏘️🗂️

5.1 brings with it a new database table to store metadata associated with sites, which allows for the storage of arbitrary site data relevant in a multisite / network context.

Cron API 🔁🔂

WordPress 5.1 includes a change in behavior for cron spawning on servers running FastCGI and PHP versions 7.0.16 and above. It also includes a change to the Cron API that updates the return values for functions used to modify scheduled tasks, it includes two new functions to assist with returning data (one to retrieve cron jobs ready to be run and another to retrieve a scheduled event), and it includes new filters for modifying cron storage.

New JS Build Process 🇯🇸🏭

The JavaScript code reorganization has been in `trunk since April 2018 and the new JavaScript build process will ship with WordPress 5.1.

Updated Styles and Strings 🔗🧵

Read below to learn about how the admin table pagination links have had their CSS styling modified to improve accessibility and how Locale Managers with commit access on the /dist repository will need to manually translate and deploy changes to files that cannot use gettext.

Other Developer ❤️

There are even more goodies in 5.1 like updates to values allowed for the WP_DEBUG_LOG constant, new test config file constant in the test suite, new plugin action hooks, short circuit filters for wp_unique_post_slug() and WP_User_Query and count_users(), a new human_readable_duration function, improved taxonomy metabox sanitization, limited LIKE support for meta keys when using WP_Meta_Query, a new “doing it wrong” notice when registering REST API endpoints, and more!

There are also a few additional changes that will receive a dev note shortly:

  • Object Caching can now degrade gracefully (#22661)
  • New parameter for the wp_check_filetype_and_ext filter (#45707)
  • New filter for filtering and overriding block attributes (#45451)

But Wait, There is More!

Over 303 bugs, 156 enhancements, 9 feature requests, and 23 blessed tasks have been marked as fixed in WordPress 5.1. Some additional ones to highlight include:

  • Bootstrap/Load: WSODs protection returns incorrect content type for JSON Requests (#45933)
  • Cache API: Allow object caches to degrade gracefully (#22661)
  • Customize: Improve browser compatibility of X-Frame-Options and Content-Security-Policy headers for window in preview iframe (#40020)
  • Customize: Use iframe sandbox attribute to restrict browsing in Customizer preview instead of attempting to rely on JS to intercept top navigation (#42341)
  • Customize: Fix counting of sections for widget sidebars, allowing non-sidebar sections to not interfere (#43556)
  • Customize: Prevent wp_targeted_link_rel() from corrupting Customizer changeset data (#45292)
  • Media: Parse the creation date out of uploaded audio files (#42017)
  • Media: No placeholder for ico file in list view of Media Library (#43458)
  • Media: media_handle_sideload() may unexpectedly return 0 on error (#44303)
  • Menus: Improve headings and instructions for better accessibility (#43397)
  • Menus: Show an appropriate message when no menus exist (#45155)
  • Networks and Sites: Improve site creation in multisite (#40364)
  • Networks and Sites: Introduce ms-site.php and ms-network.php files (#40647)
  • Networks and Sites: Implement wp_initialize_site() and wp_uninitialize_site() (#41333)
  • Plugins: Disable “Install Plugin” button for PHP required version mismatch (#43986)
  • Privacy: Show the comment / awaiting moderation message even without opt-in (#43857)
  • Query: post__in orderby not working when passed in an array to orderby (#38034)
  • REST API: Allow to filter the query in the search controller (#45454)
  • Taxonomy: Add un|registered_taxonomy_for_object_type action (#44733)
  • Users: New filter to short circuit WP_User_Query results (#44169)
  • Widgets: Make the Widgets screen “Enable accessibility mode” link more discoverable (#42778)
  • Widgets: Fix Gallery Widget preview after an image is deleted (#43139)
  • Widgets: Fix custom HTML widget editor content not updating after save (#43657)

Please, test your code. Fixing issues helps you and helps millions of WordPress sites.

Props @desrosj for contributing to this guide.

#5-1, #field-guide

#core-privacy Office Hours Minutes – 13 February 2019

The following is a summary of the weekly core-privacy office hours held on 13 February 2019. Weekly privacy office hours are held every Wednesday at 19:00 UTC. A full transcript can be found here in the #core-privacy channel in the Make WordPress Slack.

Participants: @desrosj @dejliglama @idea15 @pepe @lakenh @chriscct7 @postphotos

Admin pointers

@desrosj has created a patch (#45999) to remove the admin pointers for the privacy features which were added in 4.9.6. The attendees agreed that the pointers’ usefulness peaked around the GDPR deadline time when the features were new, but they are no longer necessary.

Workplan for 5.2

The team agreed ten tickets to focus on for release 5.2, all of which are bugfixes or enhancements of existing tools.

The bug scrub for Monday 25 February will focus on 5.2 tickets, and the bug scrub for Monday 4 March will focus on component tickets marked awaiting review.

Component roadmap

@desrosj and @dejliglama have cleaned up the draft roadmap for the component’s work in 2019. The group will finalise all outstanding issues on the roadmap during office hours on Wednesday 20 February, and will post the final roadmap to Make.

Candidates for feature plugins

The roadmap process has included discussions of which new features would be best delivered as plugins. These include embed privacy controls, WP-CLI support, multisite support, and Gutenberg blocks for data export and erasure requests.

Google Fonts

In response to privacy and performance concerns about Google Fonts (#46169, #46170), @pepe is creating a proof of concept patch to add a customizer option to disable Google Fonts for the older (pre-Twenty Nineteen) default themes.

Upcoming WordCamp/conference privacy talks

Cross-CMS privacy working group report

The cross-project privacy team is creating a draft workflow to audit project plugins, modules, and extensions for best privacy practice. The workflow is designed to be adapted to each project’s specific needs. Please review and comment on the first draft.

#core-privacy