WordPress 5.4 Field Guide

WordPress 5.4 is shaping up to be the best WordPress 2020 has seen!

As a user, you’ll see new blocks and enhancements in the block editor, new embeds, and improvements in the WordPress Admin experience.

As a developer, you’ll see 122 enhancements and feature requests, 210 bug fixes, and more! Of course, all those improvements mean code changes, which could in turn require you to make updates to your site, plugin, or theme.

So take a look through this Field Guide, and see what’s relevant to you and your users, among the many improvements coming in 5.4…


On the 14 updates related to Accessibility in 5.4, you’ll want to particularly note changes to the WordPress Admin Bar, to the calendar and recent comments widgets, on the Menu screen, and bugs reported by the WPCampus accessibility report.

Block Editor

The block editor has continued its rapid iteration since WordPress 5.0. Now it has Gutenberg version 7.5 bundled with WordPress 5.4; that’s ten releases all bundled into WordPress 5.4 (versions  and 7.5)! Bug fixes and performance improvements from Gutenberg versions 7.6 will also be part of 5.4.

The WordPress 5.4 Beta 1 post highlights a lot of new features and improvements across these releases, though you’ll also want to note the impressive achievement of 14% loading-time reduction and 51% time-to-type reduction (for a particularly long post of ~36,000 words, ~1,000 blocks) since WordPress 5.3.

Below you’ll find details on two new blocks, button component updates, block collections, default fullscreen mode for new installs/devices, custom keyboard shortcuts, general block editor API updates, new block variations API, a new gradient theme API, markup and style-related changes, and a new @wordpress/create-block package for block scaffolding.


On the 14 updates of the Customizer component, WordPress 5.4 improves accessibility of focused elements as a follow-up to WordPress 5.3 Admin CSS changes, adds documentation of existing Customizer functions and hooks, removes apple-touch-icon-precomposed deprecated meta tags, and improves Menu items selection logic.

Please note that some unused Customizer classes are now formally deprecated:


On the 5 updates in the Menus component, WordPress 5.4 improves keyboard accessibility of the Menu items selection tab panel and streamlines the user interface.

If your plugins add custom fields to menu items, you’ll want to update your code to use the new wp_nav_menu_item_custom_fields hook:


On the 15 updates in the Privacy component, you will want to specifically note:

  • Personal Data Export now includes Session Tokens, Community Events Location and Custom User Meta.
  • Personal Data Exports now include a JSON file and a Table of Contents
  • New filters for the headers of all Privacy-related emails
  • The privacy tables are improved for a cleaner interface
  • wp_get_user_request_data() function was replaced with wp_get_user_request() for better clarity

All those changes are in this dev note:


On the 22 updates related to the REST API, WordPress 5.4 now supports “OR” taxonomy relation parameter in Post Controller, adds selective link embedding and introduces some changes in the WP_REST_Server method. Read below for more details on these updates:


On the 3 updates to the Shortcodes component, WordPress 5.4 introduces documentation improvements and a new function: apply_shortcodes. This function is an alias of do_shortcode, which is still supported.


On the 9 updates to the Widgets component, WordPress 5.4 introduces accessibility and user interface enhancements on the Widgets Admin screen and changes in the Recent Comments and Calendar Widgets HTML markup.

Other Developer Updates

There are even more goodies in 5.4, like the new wp-env (a zero config tool for painless local WordPress environments), enhancements to favicon handling, better information about errors in wp_login_failed, a new site ID in multisite’s newblog_notify_siteadmin filter, a new TikTok video embed and removal of the CollegeHumor embed, storing the original URL of media attachments in _source_url post meta, improved accessibility by loading the Admin Bar with wp_body_open, avoiding duplicate IDs in the Recent Comments widget, a new parameter in the lostpassword_post action in retrieve_password(), theme headers supporting “Requires at least” and “Requires PHP” declarations, and the delete_posts capability won’t trigger PHP notices for custom post types. Read through the dev notes below to see details on all these changes coming in 5.4.

But Wait, There is More!

Over 198 bugs, 121 enhancements and feature requests, and 8 blessed tasks have been marked as fixed in WordPress 5.4. Some additional ones to highlight include:

  • Bootstrap/Load: Enhancement to favicon handling (#47398)
  • Bundled Theme: Twenty Twenty: Add social icon for WhatsApp (#49098)
  • Comments: Add “In response to …” before threaded comments in comment feed (#43429)
  • Comments: Add “in reply to” in comment moderation email notification (#43805)
  • Embeds: Embed support has been added for TikTok (#49083) (Gutenberg#19345)
  • Embeds: Removal of CollegeHumor embed as the service doesn’t exists anymore (#48696) (Gutenberg#18591)
  • Login and Registration: Clearer information about errors in wp_login_failed (#49007)
  • Login and Registration: new parameter passed into the lostpassword_post action in retrieve_password() (#38334)
  • Networks and Sites: Site ID has been added to the newblog_notify_siteadmin filter for multisite installs (#48554)
  • Networks and Sites: switch_to_blog() and restore_current_blog() reuse switch_blog action (#49265)
  • Media: store the original URL of the attachment in the _source_url post meta value (#48164)
  • Menus: Make tabs panels more accessible for keyboard users (#49211)
  • Posts, Post Types: Use delete_posts without triggering PHP notices in every post type (#30991)
  • Post Thumbnails: Make sure get_post_thumbnail_id() returns an integer, to match the documented return value (#40096)
  • REST API: Expose all theme supports and changed permissions in /themes endpoint (#49037)
  • Site Health: Theme headers support “Requires at least” and “Requires PHP” declarations (#44592)
  • Toolbar: The Admin Bar is now loaded with wp_body_open when available (#47053)
  • Widgets: Avoid duplicate IDs in Recent Comments (#46747)

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

Props to @jeffpaul and @marybaum for contributing to this guide.

#5-4, #field-guide

Dev Chat summary – April 1, 2020

@davidbaumwald led the chat on this agenda.

Full meeting translate on Slack.

This is the first devchat after the release of WordPress 5.4.


WordPress 5.4 “Adderley” was released yesterday, March 31, 2020 as scheduled.

@audrasjb shared the stats for contributors to the release. There was a total of 552 contributors from 48 countries, 32% of them being new contributors. For more accurate release contributors statistics, please fill in your WordPress profile (if you want).

Highlighted Blog Posts

@davidbaumwald shared the posts of Core Privacy team about the WP Consent API feature plugin proposal and the Guidelines for Internet Explorer 11 support in WordPress.

Upcoming Releases

@davidbaumwald reminded that 5.5 has been in Alpha phase for a while now.

Components Check-in

@audrasjb announced the release of version 0.4 of Auto-updates plugin which contains all features initially planned fot the project; as well as Themes updates and email notifications. Design, copy and accessibility reviews and feedback are welcome from plugin authors and WordPress developers.

Open Floor

@howdy_mcgee called for a feedback on these old Trac tickets: #29418, #39447, #46768, #37245, #38074, #37255 and #24142.

@azaozz shared the link of WordPress 5.4 master list in support forums. Please, go through this before posting a topic in the forums.

@ipstenu and @azaozz called for attention on respectively these two tickets #49753 and #4975, related to 5.4.

@howdy_mcgee pointed to #24780 and said he has made a document to track the supression operators in Core codebase.

@jeffpaul asked we should start taking a look at the 5.5 early tickets to review patches and look to get some of those in sooner. Here’s for reference the Trac query for 5.5 tickets.

@jeffpaul also suggested to schedule an early-specific bug scrub in the next couple of weeks to help move those tickets along. A few people voluntereed to lead these scrubs.

@bph reminded that the WPBlockTalk is happening on April 2, and everyone is welcome to register here.

#5-4, #5-5, #dev-chat, #summary

CSS Chat Agenda: 2nd April 2020

This is the agenda for the upcoming CSS meeting scheduled for 2nd April, 21:00 UTC.

This meeting will be held in the #core-css channel  in the Making WordPress Slack.

If there’s any topic you’d like to discuss, please leave a comment below!


  • CSS audit status update
  • Open floor

#agenda, #core-css

Editor chat summary: 2020 April 1

This post summarizes the latest weekly Editor meeting, held in the #core-editor Slack channel, on Wednesday, April 1, 2020, 14:00 UTC. These meetings coordinate collaboration in the development evolution of the Gutenberg project. Today’s agenda found here: 


Gutenberg 7.8.0 released last week

WordPress 5.4 Release 31 March 2020 – Field Guide
No incidents happened during the release and it already contains 2.6 million downloads

Weekly Priorities

  • The team reached a milestone closing 10,000 PRs
  • The April plan is published and includes
    • Full Site Editing: Continue improving the Edit Site screen and blocks
    • Global Styles: This will be a big one this month (support in blocks and UI)
    • Updated Inserter UI to support patterns and blocks
    • Updated Navigation/Menus screen
    • Continue G2 iterations
  • Release of 7.9 will be pushed one week to account for additional work on Global Styles project that can have some impact on themes. The extra week would be useful to polish the global styles support across different blocks and document the potential impacts properly. 
  • Release of 5.4.1 is not scheduled. Please mark PR’s/issues with `Backport to WP Core` and keep an eye for potential high impact issues that we may want to include in it.

Task Coordination


Besides the release, last Friday, we also did a WordPress 5.4 RC 5 that included some fixes to problems discovered with the editor. More details of the fixes can be found here and here.

The Good news is WordPress 5.4 is out with no incidents reported during the release and It already has 2.6 million downloads. The situation in the world was far from normal, but we managed to take the release to the finish line and solve the critical issues as soon as they were discovered/reported, so thank you a lot to all that made this possible


  • Block support for some of the Global styles variables (mainly colors)
  • Patterns API and UI


  • Pushing forward Global Styles at edit-site
  • Making font-size an implicit attribute of the block.
  • For next week, carry on with those and revive this exploration for Global Styles that uses general variables while allowing for targeting specific blocks.


  • Supporting release a bit with forums
  • Feedback flow: global styles
  • Navigation: focusing back on block and nav-menus.php
  • Triage always be triaging


  • Helping stabilize build failures to help unblock people from their work.
  • Prompting new contributors to link their GitHub account for props PR 21221 is now merged
  • A few other developer experience related improvements


  • Starting last week I am focusing back on Navigation block and nav-menus.php
  • Work from the past two weeks is blocked by lack of reviewers. There are several PRs open and waiting for reviews / comments with new features for the Latest Posts block. 


  • Continue to work on “Design Tool” issues 
  • Continue adding/improving style attributes to blocks to enable better customization

PRs Needing Review

Refactor ReusableBlockEditPanel to use hooks (and add type info) 21181
Navigation block: show color controls in toolbar only. 20884 
[Latest Posts] adds author option to latest posts block 20595
Refactor ReusableBlockEditPanel to use hooks (and add type info)  21181
Add tags in latest posts block 20785
Table of Contents block 21234
Insert post title instead of URL, when adding a link to an existing post 21240 
This issue needs review for a possible PR:
Bug: Link sometimes embeds other times not. 21029 

Open Floor

@julescole PR 21240 Insert post title instead of URL, when adding a link to an existing post

@tobifjellner WordPress TracAPP  #49752 Layout issue in WP 5.4 Needs design feedback

@paaljoachim I am very hyped on @shaunandrews PR 21121 as I believe it would make going in and out of full screen a lot easier. But we can wait and see what kind of feedback shows up in regards to the full screen mode that is included in 5.4. (edited) 

@paaljoachim I think the Embeds bug issue would fit nicely into 5.4.1. There are multiple aspects to it.

@zebulan For fun, I made a PR to refactor ReusableBlockEditPanel to use hooks. I have no idea if it runs faster (or how to even test that), but the code feels cleaner to me. Also, the PR adds JSDoc type information. Reviews/feedback are welcome as always. Also can use some eyes on a Table of Contents PR.


Having an issue with not being able to grab unpublished permalinks. You can read more about it in core-js but the gist of it is that I’m not sure where the change should occur.


When we actually click to preview it, it can’t use the future permalink because it isn’t live yet. That won’t route and will return a 404. So we have to use the ?p=123 type link for the href on scheduled posts. But we could generate what it would look like using the permalink template and placeholders

Dev Chat Agenda for April 1, 2020

Here is the agenda for the weekly meeting happening later today: Wednesday, March 25, 2020, at 09:00 PM UTC.


WordPress 5.4 “Adderley” was released yesterday, March 31, 2020!

Highlighted blog posts

Components Check-in

  • News from components
  • Components that need help
  • Cross-component collaboration

Open Floor

Got something to propose for the agenda, or a specific item relevant to our standard list above?

Please leave a comment, and say whether or not you’ll be in the chat, so the group can either give you the floor or bring up your topic for you, accordingly.

This meeting happens in the #core channel. To join the meeting, you’ll need an account on the Making WordPress Slack.

#5-4, #agenda, #devchat

Feature Plugin Proposal: WP Consent API

As part of the core-privacy team’s roadmap the team has started development on a Consent API as a feature plugin.

We welcome all thoughts on this proposal, which you are welcome to leave as comments on this post, or share with us directly in the #core-privacy channel on Making WordPress Slack. We host weekly office hours on Wednesdays at 19:00 UTC, see the meetings page for times in your timezone.


A standard way for WordPress core, plugins, and themes to obtain consent from users should be established to provide a consistent and stable experience for administrators, developers, and users of all kinds.

Currently it is possible for a consent management plugin to block third party services like Facebook, Google Maps, Twitter, if a user does not give consent. But if a WordPress plugin places a PHP cookie, a consent management plugin cannot prevent this.                                         

There are also WordPress plugins that integrate tracking code on the client side in javascript files that, when blocked by a consent management plugin, break the site. Or, if such a plugin’s javascript is minified, causing the URL to be unrecognizable, it won’t get detected by an automatic blocking script.

Lastly, the blocking approach requires a list of all types of URL’s that place cookies or use other means of tracking. A generic API which plugins adhere to can greatly help a webmaster in getting a site compliant.

Does usage of this API prevent third party services from tracking user data?

Primarily this API is aimed at helping to achieve a compliant use of cookies or other means of tracking by WordPress websites. If a plugin or custom code triggers for example Facebook, usage of this API will be of help to ensure consent. If a user manually embeds a facebook iframe, a cookie blocker is needed that initially disables the iframe and or scripts.

Third-party scripts have to be blocked by a blocking functionality in a consent management plugin. To do this in core would be too intrusive, and is also not applicable to all users: only users with visitors from opt in regions such as the European Union require such a feature. Such a feature also has a risk of breaking things. Additionally, blocking these and showing a nice placeholder, requires even more sophisticated code, all of which should not be part of WordPress core, for the same reasons.

That said, the consent API can be used to decide if an iframe or script should be blocked.

How does it work?

There are two indicators that together tell if consent is given for a certain consent category, e.g. “marketing”:

  1. The region based consent_type, which can be optin, opt out, or other possible consent_types;
  2. The visitor’s choice: not set, allow or deny.

The consent_type is a function that wraps a filter, wp_get_consent_type. If there’s no consent management plugin to set it, it will return false. This will cause all consent categories to return true, allowing cookies and other types of tracking for all categories.

If optin is set using this filter, a category will only return true if the value of the visitor’s choice is allow.

If the region based consent_type is opt out, it will return true if the visitor’s choice is not set or is allow.

Clientside, a consent management plugin can dynamically manipulate the consent type, and set the applicable categories.

A plugin can use a hook to listen for changes, or check the value of a given category.

Categories, and most other stuff can be extended with a filter.

Existing integrations

  • Cookiebot
  • Complianz
  • Example plugin. This plugin basically consists of a shortcode, with a div that shows a tracking or not tracking message. No actual data tracking 🙂

Demo site

Plugins used to set this up:

Technical Scope

The feature plugin should at least handle the following functionality:

  • PHP functions to set the consent level and consent type.
  • PHP functions to retrieve the consent level and consent type.
  • Javascript functions to set the consent level.
  • Javascript hook that fires when a consent level is set.
  • Javascript functions to retrieve the consent level.

Introducing the Feature Plugin

What’s next?

Once the plugin is confirmed as a feature plugin, the next steps would be:

  • To increase the number of users of the feature plugin.
  • To add other interested privacy team members and core developers as contributors of the plugin.
  • To have additional Third-Party consent management plugins to adopt the API.
  • To iterate on the feature plugin development.
  • To audit some specific aspects of the feature plugin:
    • security
    • coding-standards and documentation
  • To create a Trac ticket to handle a potential future merge proposal – if the feature plugin deserves it.

Post written by @rogierlankhorst / @paapst and reviewed by @garrett-eclipse / @carike

#consent-api, #core-privacy, #feature-plugins, #privacy, #privacy-roadmap

What’s next in Gutenberg? (April)

This is a monthly update containing the high-level items that Gutenberg contributors are focusing on for the next month. Join us in our efforts.

Full Site Editing

Work on this major focus is ongoing and is expected to continue iterating over the next months.

The team is still working on the Edit Site UI in order to bring parity with the Post Editor, support more template-management related features and improve the FSE blocks.

The important tasks have been splitted into sections and highlighted on this overview issue.

Global Styles

The Global Styles work is a major focus for this month. One of the most important aspect here is to add support for the global styles configurations (variables) to multiple blocks.

Some blocks have already been updated to support color settings and line height. This trend is expected to continue and expand to other settings and other blocks.

At the same time, the Global Styles UI is being iterated on the Edit Site screen.

You can follow the progress of this project on this overview issue.

Patterns & Inserter UI

Recently, the Patterns feature and APIs have been added to the editor. The UI is still experimental and an overall redesign of the inserter to absorb both blocks and patterns is one of the month’s priorities.

The team will continue to explore adding more patterns. This highlighted a need for more advanced block tools and customizations.

Updated Navigation Screen

A new experimental Navigation Menu screen is being explored and will serve as a block-based replacement for the existing menus page.

Refining the interface

The previous releases saw a big UI update for the editor. The team will continue to iterate based on the remaining tasks and the user feedback.

While these are our focuses don’t forget you can always help with triage, needs testing issues, good first issues and reviewing PRs.


Editor Chat Agenda: 1 April, 2020

Note taker and facilitator: @pbrocks

This is the agenda for the weekly editor chat scheduled for 2020-04-01 14:00 UTC.

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

  • WordPress 5.4 released
  • Planning 5.4.1
  • Monthly Plan & Weekly Priorities
  • Task Coordination
  • Open Floor

If you have anything to share for the Task Coordination section, please leave it as a comment on this post.

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


Guidelines for ancient browser support: IE

WordPress still officially supports IE 11, and will likely have to continue support for it for a while. But there is not a huge amount of people using it anymore, and there’s some indication that quite a few of the people still using it may be screen reader users.

On the other hand, there are lots of new-ish features, particularly in CSS, that it would be very useful to start exploring.

A graceful degradation approach might be the best way to allow WordPress to leverage the potential of new tech, without ruining the experience for those who still rely on legacy browsers. But how to go about adopting this approach?

Graceful degradation ensures essential functionality is still available for IE users, and features lacking IE support are used only for enhancements. What is essential is not always obvious though, so it would be good to agree on some rules for how to go about this.

I’ve created a Trac ticket for this task. It would be lovely to get some discussion going on this, either there or here!

CSS Chat Summary: 26th March 2020

Full meeting transcript on Slack: https://wordpress.slack.com/archives/CQ7V4966Q/p1585256425000800

I (@isabel_brison) facilitated the meeting. 

CSS audit updates

  • I looked into our possibilities for visual regression testing and found that jest-image-snapshot integrates very well with our existing e2e testing tools. I’m preparing a prototype branch that I will share on the ticket soon.

Open Floor

@sabernhardt requested feedback on a patch for adding print styles to wp-admin. Discussion ensued, and we agreed that:

  • Currently, when printing out wp-admin, the only thing that doesn’t show is the admin bar. This is not optimal, and print styles should remove all interface features not relevant to page content.
  • The print styles should apply to all wp-admin pages that have content and/or lists.
  • Work on the initial ticket should attempt to hide all common interface elements for print
  • If much further work is needed on individual pages, we should create sub-tickets for easier tracking/review.

And that was all for this week!

#core-css, #summary

Dev Chat summary – March 25, 2020

@francina facilitated the chat on this agenda.

Full meeting transcript on Slack

This devchat marked week 11 of the 5.4 release cycle.


WordPress 5.4 Release Candidate 4 was released on Tuesday March 24, 2020 and everything went smoothly.

@audrasjb shared an update on WP Auto-updates Feature Plugin: it was moved from his personal GitHub account to WordPress/wp-autoupdates which is the new official GitHub repository of this project. The #core-auto-updates team will try to ship version 0.4 before WP 5.4 is released. This new version aims to handle auto-updates for themes.

@afragen asked for a review of some Trac tickets which are all associated with Theme compatibility checks and will likely have interaction with the auto-updates feature. The idea is to ship them early in WordPress 5.5.

@whyisjake pointed out that he really like the work that is going on in #core-auto-updates Slack channel and think that trying to land in the next few releases would be excellent. Related, He’d love to see #core-passwords (two-factors authentification – 2FA) land in core too. In his opinion, the plugin is so mature at this point that having it left out almost seems like an omission. @whyisjake is going to work on a merge proposal.

@clorith raised that it would be necessary to make sure that the 2FA proposal also highlights the concerns with how to address users locking them selves out (which was the major holdback previously).

@azaozz announced that the patch for image lazy-loading attribute is ready for testing.

Upcoming Releases

The current major is 5.4, scheduled to go out on March 31st 2020; please keep testing for all the bugs!

There are two ways do it:

Trunk has been branched to 5.5 on the beginning of March. That means 5.5 is officially in Alpha.

@francina announced that work for 5.6 –which is going to be an all-women release– has kicked off with an initial round of messages going out to the women that expressed interest. @angelasjin @francina and Chloé Bringmann are contacting them to hear if they are still interested, what skills they have and what expectations.

Components Check-in

@francina shared a proposal to change the Components Check-in. This is always done towards the end of the chat and feels rushed. There is never really time to dig into the topics they might bring up. Francesca shared two ideas:

  1. Schedule a weekly post where they can leave their status update, like the one for Community deputies.
  2. Adopt a Slack Bot that once a week will ask the maintainers for a status update: maybe in a new component-maintainers Slack channel. Core is getting very busy with Trac and Travis bots, and RSS.

@johnbillion added that trying a weekly post could be a good idea. Maybe every Tuesday so it’s ready for the dev chat on Wednesdays in case anything comes up.

@francina proposed to talk to #meta to set this up and test drive it for 8 weeks.

Open floor

@isabel_brison proposed to create a set of guidelines for Internet Explorer support. The CSS team kind of decided on starting to deprecate it, and “graceful degradation” seems a good way to go forward, meaning Core can use unsupported technology to make non-essential enhancements. Isabel wants to agree on what’s “essential” here, and created a Trac ticket to start the discussion: #49696

@paaljoachim suggested to punt default full screen mode to 5.5 as there is a pull request on Gutenberg project GitHub repository to provide an alternative approach.

@audrasjb pointed out that the proposal in this pull request would be a way better than the current implementation.

@whyisjake added that this is not a realistic change for WP 5.4, it’s a proof of concept, and not a fully tested feature.

@francina confirmed that @matt took the decision to ship WordPress 5.4 with this feature. Matt also commented in the Accessibility Team statement post.

@joyously stated it’s hard to contribute when concerns are ignored. @chanthaboune answered she can understand how they can feel ignored. A lot of that research gets done solo, and it’s often hard to remember to recap your own research. For full site editing to be a reality by the end of the year, the work can start bringing incremental changes. This change is feeling very jarring, but there is more worry about not have any mid-point between here and Full Site Editing.

@peterwilsoncc, @clorith and @audrasjb agreed that since RC4 was released, it’s not realistic to revert this change. The discussion can continue in a post-mortem post on Make/Core.

#5-4, #5-5, #5-6, #dev-chat, #feature-autoupdates, #feature-lazyloading, #two-factor