WordPress 5.1 Release Day

We’re less than 24 hours away from WordPress 5.1! If you’d like to help get this release out the door, here’s how you can join in.

The current plan is to start the release process at February 21th, 2019 at 22:00 UTC, in the #core Slack channel.

The major version release process can take a bit more time than the betas or Release Candidates, particularly if we run into any last minute issues that need to be addressed.

The Release Process

We’ll be working through the Major Version Release process, for anyone who wants to follow along.

I ran through the Dry Run steps earlier, there was one file missing from $_old_files (#46284).

How You Can Help

A key part of the release process is checking that the zip packages work on all the different server configurations available. If you have some of the less commonly used servers available for testing (IIS, in particular), that’d be super helpful. Servers running older versions of PHP and MySQL will also need testing.

In particular, please test:

  • Does a new WordPress install work correctly? This includes running through the manual install process, as well as WP-CLI or one-click installers.
  • Does it upgrade correctly? Are the files listed in $_old_files removed when you upgrade?
  • Does Multisite upgrade properly?
  • Run through some basic usage flows, both on desktop and mobile:
    • Publish a post, including a variety of different blocks.
    • Comment on the post.
    • Install a new plugin/theme, or upgrade an existing one.
    • Change the site language.
    • If you’re a plugin developer, or if there are complex plugins you depend upon, test that they’re working correctly.

You can even start this early, by running the WordPress 5.1 RC2 packages, which are built using the same method as the final packages.


WordPress 5.1.1

A part of last week’s devchat contained a discussion about short-cycle maintenance releases and how they are handled. Another post will be published to discuss this longer term. But, a short term plan for 5.1.1 needs to be established so component maintainers and committers can prioritize their efforts in the coming weeks.

Keeping with the recent 2-week minor release cadence used in the 5.0.x releases, and with the proposed 5.2 release schedule in mind, this is the proposed release schedule for WordPress 5.1.1:

  • March 4, 2019: 5.1.1 RC
  • March 7, 2019: 5.1.1 Release Date

Given the shorter release timeline and the quick turnaround of 5.2, 5.1.1 should only consist of:

  • Important bug fixes.
  • 5.1 regressions.
  • Small block editor improvements.

If 5.1.2 is deemed necessary, the same 2 week cadence will be followed, making the preliminary, if necessary release date for 5.1.2 as March 21, 2019.

Release leads have not yet been determined for this release. If you are interested, please comment below. Since this is a smaller release, it is a great opportunity for someone interested in helping with their first release.


Dev Chat Summary: February 13

This post summarizes the weekly dev chat meeting from February 13th (agendaSlack archive).

5.1 updates

5.1 is currently on target for the Feb 21 release date.

RC1 went out last week. Two remaining bugs have been fixed (remaining open tickets can be tracked here). Right now, all that is left is the About page, which needs some design work and some minor bug fixes. @pento expects to release a small RC2 either late this week, or early next week.

The WordPress 5.1 Field guide is out, thanks to the hard work of @desrosj, @jeffpaul, and the many contributors who wrote individual dev notes for this release.

Since the meeting adjourned, 5.1 has been branched, and Trunk is open for 5.2–alpha enhancements.

5.2 and 5.1.x Logistics

Release target and cadence

Based on the desire to update the PHP requirements in April, @pento proposed targeting late April for a 5.2 release. That leaves about a month for alpha, a month for beta, and two weeks for RC.

@youknowraid proposed shortening the release cycles for WordPress to shorter, predictable cycles that are time-based instead of feature based. After some discussion, @chanthaboune suggested an official proposal be drafted on https://make.wordpress.org/core, and @desrosj volunteered to help draft the post.

Potential features for 5.2

While there are no firm commitments, a few ideas for 5.2 features include:

  • Gutenberg performance and UX improvements
  • Core widgets converted to blocks
  • PHP Fatal Recovery (WSOD)
  • Site Health Check

5.1.X Releases

Barring any major regressions in 5.1, the target for a 5.1.1 release will be 2 weeks after 5.1. With 5.2 targeted for April, 5.1.x releases will be limited to 5.1 regressions and important bug fixes that would be good to get out earlier, and exclude additional features or enhancements.

Updates from focus leads and component maintainers

An initial implementation of CODEOWNERS file in Gutenberg was merged, which is kind of a joint JavaScript and Gutenberg update.

From the Gutenberg desk: there is a lot from last week’s meeting, but there is a call for reviewers that’s worth taking a look at.

From Media: the team did a ticket triage and left excellent notes with calls for testing and patches.

From the JavaScript desk: There’s a request for feedback from @youknowriad on how to tackle selecting data over multiple stores.

General announcements and open floor

The Navigation block is currently being discussed and there are mockups in GitHub that would benefit from people’s feedback.

@afercia proposed an audit of the project’s components and maintainers soon to ensure the project is properly organized to maintain all parts of the codebase and increase participation where necessary.

Additionally, @afercia recommended that all components and teams use the correct headings level when authoring a post, and please refrain from using emojis or other extraneous content within the headings. This relates to an ongoing effort to improve the headings hierarchy across the .org network.

Finally, @chanthaboune published a post titled, Strengths and Challenges: Follow Up, earlier this week. Everyone should read it, as it applies to all teams. Additionally, she is working on the first “Scrum of Scrums/Weekly Digest/Wayfinding” post, which she expects to publish later this week.

#5-1, #core, #dev-chat

Dev Chat Agenda: February 13

Below is the agenda for the weekly devchat meeting on Wednesday, February 13, 2019 at 21:00 UTC:

  • 5.1 updates:
    • Schedule update
  • Updates from focus leads and component maintainers
    • The Navigation block is proving to be complex, and simplifying it requires breaking it down into smaller issues that need your feedback.
  • Open Floor

If you have anything to propose for the agenda or specific items related to those listed above, please leave a comment below.

This meeting is held in the #core channel in the Making WordPress Slack.


#5-1, #agenda, #core

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

Dev Chat Summary: January 30th

This post summarizes the weekly dev chat meeting from January 30th (agendaSlack archive).

5.1 updates

Beta 3

5.1 Beta 3 was delayed by 24 hours following issues with the PHP error recovery (aka WSOD) feature. The current plan is to release beta 3 a few hours following the dev chat today.

Schedule update

Remaining planned schedule dates remain the same, with RC 1 and a hard string freeze on February 7 and a final release planned for February 21.

See also: WordPress 5.1 Development Cycle

Dev notes status report

All but three dev notes planned for 5.1 have been published

@desrosj is continuing to coordinate 5.1 dev notes. There are also plans to release a Field Guide for 5.1 on the day that RC1 is released. If any component maintainers have information they would like to have included in the Field Guide, please provide them to @desrosj before February 6, 2019.

Updates from focus reps and component maintainers

Meeting notes and summaries

Other calls/proposals

  • The REST API team is aiming to have owners for every ticket milestoned for WordPress 5.2, so could use more help if people are looking for tickets to work on.

PHP error recovery (WSOD) update

Earlier this week, security concerns were raised about this feature, which ultimately has lead to the decision by the #core-php team to revert this feature from 5.1 and try again in 5.2 in order to adequately address the issues identified. For additional context, people can reference the original ticket (#44458) and the new ticket created to track new refinements (#46130).

Continued work on this feature will be coordinated in #core-php on Slack and during weekly meetings on Mondays at 16:00 UTC.

Additional follow up

  • @flixos90 is in touch with the original reporter of the security concern.
  • @aaroncampbell agreed to follow up with the author of the ZDNet article to inform them about the feature being removed. The article has since been updated to reflect this change.
  • From a marketing perspective, @joostdevalk reminded that because of the open nature of our project, these kinds of things are going to happen, which isn’t itself a concern, as long as we are actively following up.

Open floor

@kadamwhite mentioned that the upcoming Gutenberg roadmap would likely require enhancements to the REST API in Core and suggested that there be closer coordination between the editor team and the REST API team regarding implementation of new features or enhancements.

It was suggested that when new features require knowledge from other teams, that the people working on those features reach out via component slack channels or in comments to component/team meeting notes, which should be published consistently by all active teams.

#5-1, #dev-chat

Dev Chat Agenda: January 30

Below is the agenda for the weekly devchat meeting on Wednesday, January 30, 2019 at 21:00 UTC:

If you have anything to propose for the agenda or specific items related to those listed above, please leave a comment below.

This meeting is held in the #core channel in the Making WordPress Slack.

#5-1, #agenda, #core, #dev-chat

WordPress 5.1 Beta 3 Delay

WordPress 5.1 Beta 3 was scheduled to be released today. It is now delayed by one day, and will be released after the core dev chat.

There are recent reports of potential security issues in the new PHP error recovery feature. To address these issues, there’s a promising patch on #46130, but it’s a significant change in behaviour to be committing this late in the release cycle. Ideally, this large a change would’ve been made before Beta 1.

There are a few options to move forward on this:

  • Continue with the fix in #46130, focussing on ensuring it doesn’t expose new potential security issues.
  • Disable the feature by default, adding a feature flag for sites to opt-in to error recovery.
  • Revert the feature from trunk, and aim to include it in WordPress 5.2, instead.

An earlier discussion in #core generally leaned towards reverting it.

Reverting the error recovery feature will not have an effect upon the PHP upgrade notices feature. Both the PHP upgrade notices and the error recovery are part of the broader Site Health project, but are functionally independent of each other.

Delaying the Beta 3 release by a day ensures that everyone involved has the opportunity to discuss the next steps.


Multisite Support for Site Metadata in 5.1

WordPress multisite introduces a new database table to store metadata associated with sites. This allows for the storage of arbitrary site data relevant in a multisite / network context.

Site metadata provides an alternative to using options and can be retrieved from multiple sites in a more performant way—without calling switch_to_blog(). Sites can now also be queried by their meta with parameters supported by WP_Meta_Query.

The new wp_blogmeta table is a global table in WordPress and developers should be cautious not to overuse it. There is a trade-off between using site options and site metadata, so it is recommended to think about every piece of extra data associated with a site and how it should be stored.

  • Use options when the data concerns only the site itself. Using an option should continue to be the default approach for site data.
  • Use site metadata when the data also needs to be heavily used in the network context, especially when sites need to be queried by it.

A network update is required to install the new database table. The site meta API includes a function is_site_meta_supported() to ensure no unexpected errors occur when that process has not run yet. As of WordPress 5.1, there is only a single use-case for the site meta in core which regards the fatal error protection mechanism (see #44458).

This is how the API can be used:

  • get_site_meta( $id, $meta_key, $single )
  • update_site_meta( $id, $meta_key, $meta_value, $prev_value )
  • add_site_meta( $id, $meta_key, $meta_value, $unique )
  • delete_site_meta( $id, $meta_key, $meta_value )

All of these functions are only available in multisite, however they work similarly to other metadata wrapper functions, such as for posts, terms, comments and users. In addition to these functions, it is now possible to use the common meta query arguments when querying sites with WP_Site_Query or its wrapper get_sites().

Note that the database table for site metadata is called wp_blogmeta. This is because wp_sitemeta is already used for another database table, and furthermore the new name works consistently alongside the related wp_blogs table that stores the most essential site data. The API exposed and described here uses the correct term “site”.

For background information on these changes, see #37923 and #40229.

An additional under-the-hood change related to this is that the metadata API is now loaded earlier in the WordPress bootstrap process so that it is available as early as the multisite bootstrap code. See #40948 for more information.

Props @jeremyfelt for review.

#5-1, #dev-notes, #multisite, #networks-sites

Dev Chat Summary: January 23rd

This post summarizes the weekly dev chat meeting from January 23rd (agendaSlack archive).

5.1 updates

Beta 2

5.1 beta 2 went out earlier this week.

There are a few tickets still open, most of them are related to fine tuning the WSOD handling.

Schedule update

Beta 3 is scheduled for January 29, this is also the soft string freeze. All string changes must be committed by then (except for the About page).

See also: WordPress 5.1 Development Cycle

Dev notes status report

5.1 is being accompanied by a nice collection of dev notes, mainly from Make/Core but also from Make/Polyglots.

@desrosj is continuing to coordinate 5.1 dev notes. There are also plans to construct a 5.1 Field Guide that summarizes collects all dev notes.

Updates from focus reps and component maintainers

Meeting notes and summaries

Other calls/proposals

Open floor

The Gutenberg Team is looking for more pull request reviewers. If you’re interested, please touch base with them in the #core-editor Slack channel. Details to be shared soon in a Make/Core Post.

About including recent Gutenberg changes in the currently scheduled release: the WordPress 5.1 cycle is being a bit stricter about non-regression bug fixes landing during the beta period, but WordPress 5.2 is expected to be able to take bug fixes during the WordPress beta period.

About the recent Post concerning the bulk edit process: many relevant opinions and thoughts were shared during the meeting.

  • @matt expressed a desire to reopen the tickets closed in the recent bulk edit.
  • @desrosj and @jeffpaul will work on a strategy for reverting closed tickets that have not been changed since the bulk edit, to allow the tickets to be properly evaluated for closure.
  • Component maintainers to review related tickets (via this custom query). However, the 5.1 release is probably going to delay the ability to do that.
  • Contributors can also use this Trac report (replacing “myusername” with their username and scrolling to those updated on January 4th) to find the tickets they have been involved with that were affected by the bulk closing.
  • A stale keyword and/or status was discussed as a good way to leave tickets open long term and avoid closing them as wontfix and maybelaterstatuses.
  • A post on Make/Core is coming next week to kick off the efforts of the new Triage Team.

This Dev Chat Summary post is open for further comments and discussions.

#5-1, #dev-chat