The WordPress core development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
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.6, 6.7, 6.8, 6.9, 7.0, 7.1, 7.2, 7.3, 7.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.
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 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.
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.
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)
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.
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.
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.
@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.)
@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
TheComponents page is getting some revisions, so it’s out of sight temporarily.
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.
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.
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.
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:
From the directory of your WordPress source code, plugin, or theme, run wp-env start.
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 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.
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.
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.
@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!
