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…

Accessibility

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 6.66.76.86.97.07.17.27.37.4  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.

Customizer

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:

Menus

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:

Privacy

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:

REST API

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:

Shortcodes

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.

Widgets

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

Bug Scrub Schedule for 5.4

Now that 5.4 has been officially kicked off, bug scrubs will happen weekly all the way up to the final release. Keep an eye on this schedule – it will change often to reflect the latest information.

  1. 1/21/2020 19:00 UTC
  2. 1/29/2020 23:00 UTC
  3. 2/7/2020 05:00 UTC (APAC-Friendly)
  4. 2/10/2020 16:00 UTC
  5. 2/18/2020 20:00 UTC
  6. 2/27/2020 23:00 UTC
  7. 3/2/2020 18:00 UTC
  8. 3/11/2020 TBD (If Necessary)
  9. 3/17/2020 TBD (If Necessary)
  10. 3/27/2020 TBD (If Necessary)
  11. 3/30/2020 TBD (If Necessary)

These scrubs are separate and in addition to the normal scrubbing and triage by individual components. Some of those sessions include:

Design Triage: Every Monday 17:30 UTC at #design
Gutenberg Design Triage: Every Tuesday 17:00 UTC at #design
Accessibility Scrub: Every Friday 14:00 UTC at #accessibility

Also, the ongoing APAC-friendly #core bug scrub session every Thursday at 06:00 UTC will continue during the cycle, alternating focus between core and editor.

Next, the Accessibility team has announced a few extra scrubs for the 5.4 cycle. You can read about those here.

Finally, a reminder that anyone — Yes, you! — can host a bug scrub at anytime. You can work through any tickets you’re comfortable with. In fact, if you plan one that’s 5.4-focused, we’ll add it to the schedule here along with your name. Finally, you’ll get well deserved props in the weekly Dev Chat, as well as in the #props Slack channel!

All open tickets for 5.4, in order of priority, can be found here. Tickets that haven’t seen any love in a while are in particular need. Those can be found in this query.

If you’d like to lead a bug scrub or have any questions or concerns about the schedule, please leave a comment or reach out to me directly.

#5-4, #bug-scrub

Auto-updates kick-off Meeting Announcement

Last week, WP Auto-updates Feature Plugin was introduced with a post on Make/Core to give everyone an idea of where it is heading.

Now, the idea is to gather more contributors around the feature plugin and get your feedback on the project.

For this, let’s kick-off regular meetings in the brand new #core-auto-updates Slack channel.

The first meeting will be held on Tuesday March 10th, 2020 at 18:00 UTC and will serve as an introduction to the project and as an opportunity to discuss the next steps.

Proposed agenda:

  • WP Auto-updates feature general scope
  • Current status
  • Next steps
  • Openfloor / issues and pull requests reviews

If you have anything specific that you’d like to propose being discussed in this meeting, feel free to leave a comment below.

This meeting is held in the #core-auto-updates Slack channel , to join the meeting, you’ll need an account on the Making WordPress Slack.

#auto-update, #feature-plugins, #feature-projects, #feature-autoupdates

Dev chat summary, March 4, 2020

The actual author is Christiana Mohr.

Editing by folks including @valentinbora, @amykamala and @marybaum.

Announcements

5.4 RC1

WordPress 5.4 Release Candidate 1 landed yesterday, March 3, as scheduled.

Thank you for your hard work making this happen!

Two ways to test: 

  1. Try the WordPress Beta Tester plugin (choose the “bleeding edge nightlies” option)
  2. Or download the release candidate here (zip).

A full list of closed 5.4 tickets is here.

There’s a new beta dashboard plugin widget with info on what to test!


Highlighted Blog Posts

The 5.4 Field Guide is Ready!

@audrasjb noted he’ll add a field guide link to the beta-tester dashboard widget. He might also link to important dev notes directly. (Ed. note: The Guide already links do every dev note from the 5.4 cycle, so if you bookmark it, you’ll have one-click access to them all from there.)

Simple Local Environments for WordPress is here. Questions? As always, let’s have a lively discussion in the comments.

Upcoming Releases – 5.4 and 5.5

We are now in alpha for 5.5!

@peterwilsoncc branched trunk as soon as RC1 landed, meaning we are officially in alpha for 5.5!

If you have a ticket or a feature, or anything you’d like to see land in WordPress 5.5, please get busy now. By the time we start discussing 5.5 in devchat later this year, we’ll be on the countdown to beta — four weeks from Beta 1, which is the hard feature freeze.

At the same time, please keep testing 5.4.

Auto-updates feature plugin has a new home on Slack

 #core-auto-updates is the new Slack channel for conversations about the new auto-updates feature plugin! 

You may recall that auto-updates is a goal for 2020 and was originally slated for 5.4—but a consensus formed around the idea that the feature needed more testing and feedback.

5.4 RC2 lands Tuesday, March 10

As of RC1, we have a hard string freeze. Plus, all commits need peer review. That said, you can always contribute to inline documentation and build- tooling changes.

Components Check-In

The Components page is getting some revisions, so it’s out of sight temporarily.

The Core Privacy Focus for 5.5 will be on multisite. Also, look for a kickoff post for the Consent API before it becomes an official beta plugin.

Open Floor

Daylight Savings Time comes to the US this weekend and to Europe in three weeks. The question: whether and when to adjust the chat time? Some folks recommended keeping the time at 21:00 UTC, Daylight Time or not. But as @davidbaumwald pointed out, the Contributor’s handbook mandates a time change. So look for that change in the next several weeks.

Ticket #49518 is an enhancement to add four i18n hooks. @pbiron explained that enhancements need to land before beta, so the ticket might land in 5.5.

Dev Chat Agenda for March 4, 2020 (5.4 Week 8)

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

Announcements

Highlighted Blog Posts

Upcoming Releases – 5.4 and 5.5

  • RC 2 to be released on March 10th
  • Trunk is now 5.5 alpha

Components Check-in

  • News from components
  • Components up for adoption (Filesystem API and Rewrite Rules)
  • Components that need help
  • Cross component collaboration

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. To join the meeting, you’ll need an account on the Making WordPress Slack.

#5-4-2, #5-5, #5-4, #agenda, #devchat

What’s next in Gutenberg? (March)

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.

Block Content Areas

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

  • Continue improving the Edit Site UI
    • Improve the saving flow. 20421
    • Improve the template selector picker. 20469 20478
  • Continue on the Full Site Editing blocks (post tags 20418, post comments 19894).
  • Work on the Block Context API. 19685
  • Continue on the experimental block-based themes.

Global Styles

  • Update the Core blocks styles to support the Global styles variables.
  • Define and document the available settings.

Patterns

These are different from the Block Variations API (that was initially named patterns as well). These are pre-made post/page sections that can be inserted and edited.

  • Create a rich built-in patterns library. 20345
  • Iterate on the Patterns UI. 17335

Tightening up

  • The first iteration of the new Block UI has been merged and it will be polished/iterated on during the upcoming month. 19344
  • Implement the first version of the Block Editor Controlling API. 20588
  • The ongoing effort to use a lighter Block DOM structure in the editor and match the frontend.

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

#core-editor

Release Model Working Group Chat Agenda – March 4, 2020

Here is the agenda for the chats happening today, Wednesday, March 4, 2020 at 08:00 UTC and Wednesday, March 4, 2020 at 20:00 UTC

This week we’ll chat about:

  • Contributor calls for status updates on assigned issues in the Github Repo 
  • Open issues that need volunteers
  • Next steps for turning research and ideas into tangible improvements to the release cycle

Looking forward to our chat!

#release-process

Core-Privacy office hours agenda for 04 Marc

With WordPress 5.4 entering the RC (Release Candidate) stage it’s time for the #core-privacy team to plan next steps. Along with planning privacy updates for 5.5, we’ll be discussing next steps for the Consent API (feature plugin), GDPR Data Request Form (feature plugin) and Compliance Tab during our office hours.

Come and join us for our office hours at our usual time this Wednesday, 04 March, at 1900 UTC on our Slack channel. All are welcome.

Our tentative agenda includes:

See you there.

#core-privacy, #privacy

CSS Chat Agenda: 5th March 2020

This is the agenda for the upcoming CSS meeting scheduled for 5 March 2020 9pm 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!

Agenda:

  • Open Floor

#agenda, #core-css

wp-env: Simple Local Environments for WordPress.

Local WordPress environments are now as simple as running a single command. wp-env is a zero config tool for painless local WordPress environments. It provides decisions over options so that users can quickly spin up WordPress without wasting time. Indeed, the goal is to make these environment easily accessible to all — whether you’re a developer, designer, manager, or anyone else. It really is this straightforward:

  1. From the directory of your WordPress source code, plugin, or theme, run wp-env start.
  2. Access the instance on localhost:8888. The local code is already mapped and ready for development!

In this basic example, there is no configuration. wp-env creates a Docker instance behind the scenes with the latest WordPress image and then maps the local theme or plugin to the environment as a Docker volume. This way, any changes you make to the code locally are reflected immediately in the WordPress instance.

wp-env requires both Docker and Node. Once these prerequisites are met, you can run npm install -g @wordpress/env to install wp-env locally. Feel free to test it out from the root of the Gutenberg repository!

For more advanced use cases, the experience is just as simple after one includes a short configuration file (called .wp-env.json) in the source code. Running wp-env start in the same directory as a .wp-env.json file will automatically start and configure everything for you according to the specifications in the file. This makes it easy for new folks to start contributing or testing in advanced environments without having to configure anything themselves.

The .wp-env.json file allows you to create fairly advanced local development setups. Here is the documentation for the config file, and below is an advanced use case:

{
  "core": "https://wordpress.org/wordpress-5.4-beta2.zip",
  "plugins": [
    "../../my-fancy-plugin/",
    "https://downloads.wordpress.org/plugin/classic-editor.1.5.zip",
    ".",
    "WordPress/gutenberg#master"
  ],
  "port": 1000,
  "testsPort": 1001,
  "config": {
    "WP_DEBUG_DISPLAY": true
  }
}

The core field allows us to specify a source for the core WordPress code. Additionally, the plugins and themes fields allow us to specify sources for plugins and themes. These sources can be in several formats: relative or absolute local paths, a GitHub repository, or a URL to a .zip file.

In the above example, we see the following:

  • The core field is mapped to a beta version of WordPress in the .zip format.
  • The plugins field contains several plugins. The first is a local path to a plugin, the next is a zip file, the third is the plugin in the same directory as the .wp-env.json file, and last is a reference to the master branch of the Gutenberg GitHub repository.
  • The port field overrides the port on which the instance is mounted. In this case, we access WordPress at http://localhost:1000.
  • The config field sets wp-config.php constants. Here, the WP_DEBUG_DISPLAY constant is set to true in the created WordPress instance.

You might need to create this file if your plugin or theme has a lot of dependencies or options required for development. Instead of offloading this configuration work to the consumer, .wp-env.json makes the development and testing of advanced setups easily accessible to anyone with wp-env installed.

Finally, props to @noisysocks and @epiqueras for making this tool possible. If you’d like to learn more about wp-env, see the documentation page, read the source code, or follow development progress. As always, feel free to open issues or pull requests on GitHub if you find bugs or have suggestions concerning the tool.

#wp-env

Fullscreen mode enabled by default in the editor

Starting with WordPress 5.4, the editor behaves differently the first time you open the editor in a new installation or on a new device—or any other time WordPress resets the user preferences.

Now the editor opens in fullscreen mode by default. Note that for now, that’s a local setting, which is why it’s going to reset when your preferences do, including incognito mode. Future releases will store the setting in the WordPress database.

Want to turn it off? It’s simple—just use the pulldown in the editor’s menu.

You can also control the editor’s mode programmatically with the data module. A quick reminder: the code below is JavaScript, not PHP.

const isFullscreenMode = wp.data.select( 'core/edit-post' ).isFeatureActive( 'fullscreenMode' );

if ( isFullscreenMode ) {
    wp.data.dispatch( 'core/edit-post' ).toggleFeature( 'fullscreenMode' );
}

#5-4, #block-editor, #dev-notes

CSS Chat Summary: 27th February…

CSS Chat Summary: 27th February 2020

Full meeting transcript on Slack.

I (@notlaura) facilitated the meeting. The agenda was:

  • Idea for a CSS audit
  • Open Floor

CSS Audit

I began the first agenda item, “Idea for a CSS audit” with some general information about CSS audits, and this could be a useful way to inform an approach for reducing specificty and using newer CSS features in WordPress. I also mentioned that, for WordPress specifically, an audit might include understanding the experience of CSS contributors since CSS can be a powerful way to bring in new folks.

I posted a few resources to information on CSS audits:

Initial thoughts were positive. @bemdesign said that reducing specificity would make things easier for the future, and @marybaum identified it would be valuable to know how much of the codebase is in use, and how much of it is something we could modernize.

The following comments indicated the scope of an audit would also be something to take into account: is this only admin CSS, or does it include themes and plugins?

@marybaum mentioned CSS in the default themes is an opportunity to model practices for other themes.

@afercia reminded us that large parts of admin CSS are also used by plugins, so we don’t want to refactor for the sake of introducing new features because it could break many plugins.

I added that the intent of a CSS audit would be to inform and update ongoing CSS standards, not solely introduction of new CSS features, and @peterwilsoncc emphasized the distinction between recommendation and accepted recommendation, and that the outcome of an audit would be more like a wish list and documentation of ideals.

I then asked about current conversations around design systems and coherence in the code-base, and linked to the Color Foundations in the Design Handbook.

@afercia mentioned that there is an additional color palette used in Gutenberg, and that the co-existence of the two palettes is an ongoing issue.

@peterwilsoncc emphasized that this type of project would involve all teams, editor, design, core, accessibility, at the very least.

These historical tickets came to light related to the audit conversation:

Open Floor

@xris asked about the importance of comments in CSS, and that most of the Core CSS seems to uncommented or that it does not follow commenting guidelines. They mentioned that the well-commented files – such as this one – are much easier to read.

The conversation then turned to the role of comments in general, and @afercia mentioned some history of the WordPress CSS comments: all CSS used to be a single, large file, and was commented when it was split into multiple files. Some of these legacy comments remain and are out of context.

I linked to the Comments section in the CSS Standards section of the handbook, and identified another high-level outcome of an audit could be to see where these standards are and are not followed throughout the code-base.

@afercia mentioned that we should publish this recurring meeting on the official / @peterwilsoncc followed up a few days later that this has been completed!

And that concludes the meeting summary!

#core-css, #summary