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.
@michael-arestad works on multi-entity saving and navigation methods within the editor
@Brent Swisher will continue working on storybook stories
Open floor
@soean asked that we announce WPBlockTalk – a free, online event for all things block editor happening on April 2nd
@paaljoachim asked about a progress with the Reusable Block feature. Progress can be monitored here.
@paaljoachim also raised awareness on PR 18718 about refactoring cover background controls.
@paaljoachim asked if we have a “how to create a PR info area: in the Core Editor handbook. Closest match is here.
Post Meeting discussion
There has been some discussion post meeting between @matveb, Pablo Honey and @mapk about the limitations of designing more complex block patterns.
To sum up the way forward is to provide the best patterns we can which don’t don’t suffer from the lack of tools and when we run into limitations to distill them down to improvements on the blocks themselves.
Topic concerns aligning naming conventions for wp globals on package exports.
Actions:
Merge pull #18722 that documents how to use ServerSideRender from the wp.serverSideRender export. (Done)
Create an issue to track the broader effort of “fixing” the names for these globals. (Done)
News Roundup
This roundup contains a few links for Gutenberg and JavaScript related news curated (and commented on) by @nerrad.
Justin Tadlock writes about Gutenberg 7.7 and the first iteration of block patterns. He makes the assertion that “Patterns will be a game-changer”. I agree. He also has some positive comments on the ui/ux refresh introduced.
An interface package has been proposed. This opens the door to exposing and using common ui interface patterns across the WordPress admin (think sidebars, fullscreen etc).
I noticed the new [Feature] Design Tools label in Gutenberg. This will likely help with some of the Block Patterns work in giving author’s more ways to affect the design of elements in patterns.
In case you were looking for an blog post about the XML Sitemaps feature project last week, worry no more. Work on the plugin is progressing smoothly and steadily, we just didn’t publish an agenda post last week. That means it is time for a double update today!
Meeting Recap: March 10th & 17th
For reference, check my previous blog post from March 10th:
A lot has happened since then. Here’s the summary, not necessarily in the right order:
SimpleXML dependency We received great feedback from a variety of big hosting providers, all saying that this PHP extension is widely available and we can rely on it safely. Current status: no action needed.
Rewrite rule conflict with plugins As we realized that the new /wp-sitemap.xml URL format clashes with big existing plugins, we decided to look into alternate names for both the rewrite rules as well as the query params. See GitHub issue for details. Current status: needs contributors.
Rewrite rule issues with custom providers It was reported that adding custom sitemap providers might require flushing rewrite rules. Ideally, that shouldn’t be needed. Current status: needs decision.
Last modified date (lastmod) We decided to continue with the proposed PR to remove lastmod from sitemaps (at least for now), but need to make sure there is appropriate documentation. It’s something that can always be added back if needed. Current status: has PR, needs documentation.
Query Filters Valuable feedback emerged from testing, which led to the decision to close the existing PR to make query instances filterable in favor of a simpler approach. In its place, we should make the query arguments filterable, and also add filters to short-circuit queries. Current status: needs contributors.
Please let me know in the comments if I got something wrong in this summary!
At the present moment, due to various circumstances, the Monday 14:00 UTC time slot for the WP Notify weekly meeting has become problematic for me. This means it is becoming more and more difficult for me to attend, let alone host these meetings.
I am therefore putting these meetings on hold until we can agreed on either a new meeting time, or chose a new meeting host to drive the weekly meetings forward.
I will leave the post open for comment for the rest of the week, or until we can agree on a way forward.
WordPress 5.4 Release Candidate 3 was released on Tuesday March 17th! 🎉Thank you to everyone that has contributed! @johannlinnarsson asked when we might expect the final 5.4 release and @marybaum confirmed that March 31 is the target release date.
Upcoming releases WordPress 5.4
WordPress 5.4 About Page: @karmatosed shared that many many folks contributed to the design and creation of the About page. Thank you to everyone that contributed. Testing is very much appreciated at this point as we prepare for release candidate 4 on March 24.
@jorgefilipecosta mentioned that there are two pull requests that are in need of review for 5.4 and those can be found at this link.
@clorith asked if there was any additional information regarding the recent changes to editor default views and there is currently no new information outside of the discussions in the blog post.
Components Check-In
@azaozz had some exciting Media updates showing off the now merged 1.1 changes for the Lazy Loading Feature Plugin and said that he will be working on a patch to introduce in trunk (5.5.) More to come soon on this much anticipated feature! If you’d like to contribute here is a link to the GitHub repo.
@audrasjb introduced some new changes to WP Auto Updates saying, “WP Auto-updates Feature Plugin version 0.3.0 was released with email notifications for plugins automatic updates. Next version will be focused on porting all the current features to themes screen.” A summary of this chat can be found at this link. If you would like to get involved in contributing to this feature, please feel free to jump into the Feature Plugin GitHub repo.
@pbiron mentioned another plugin that could benefit from some testing; Core Sitemaps plugin is aiming for an early inclusion into 5.5. Please feel encouraged to test it ahead of time! If you’d like to contribute to this feature, explore the GitHub repo!
@aduth provided a #core-js update around their processes. He said, “In the #core-js chat this week, it was suggested to share that our weekly meeting summaries are now including a “News Roundup” of JavaScript and Gutenberg-related items, for those who might be interested or think it helpful to keep in the loop. “ A link to that can be found at the end of this summary post.
Props to @garrett-eclipse for the peer review of this summary. 🙏🏼
Until May last year, contributions to WordPress Core were bound to PHP 5.2 syntax and most plugins and themes stuck to the PHP 5.2 minimum requirement as well.
However, with the change to PHP 5.6 as the minimum PHP version for WordPress Core, new PHP features have become available for use in WP Core and with the outlook of a minimum version of PHP 7.x in the (near) future, even more interesting language features will soon become available for use in WordPress Core, plugins and themes.
With that in mind, we’d like to define coding standards for a number of these constructs and propose to implement automated checking for these in the WordPress Coding Standards tooling in the near future.
While it may still be a while before some of these features will actually be adopted for use in WordPress Core, defining the coding standards in advance will allow for a consistent code base when they do get adopted and will allow for plugins and themes, which are not necessarily bound to the PHP 5.6 minimum, to safeguard their code consistency when they start using more modern PHP already.
To be honest, none of these proposals are terribly exciting and some may not even seem worth mentioning. Most follow either prior art in WordPress Core or industry standards for the same, but in the spirit of openness, we’d like to verify our take on these before implementing them.
I tested some automated tools we might use for the audit and updated 49638 with my findings;
@notlaura attended the design meeting and asked what designers would find useful with this audit (summary here).
Todoes
Create a doc for the audit outline.
Ask the accessibility folks what they would find useful as an audit outcome.
We also discussed and agreed on reviewing, as part of the audit, where we are using px units and others that might have a detrimental effect on responsive behaviour.
Coding standards
I asked about the history of stylelint-config-wordpress, which is used in Gutenberg but predates it by a few years.
@netweb later replied with some informative context that I will add here:
The Stylelint config was created with Core in mind, based on existing styles and in alignment with PHP and JS standards.
It was then updated when added to Gutenberg, especially the Sass-specific rules.
It wasn’t added to Core because it was picking up lots of errors that would need to be fixed, so needed a committer to own the work.
The discussion then shifted to use of Grunt and Sass in Core. Sass is mainly used for theming in wp-admin, and the design team are looking at replacing its use with CSS custom properties.
(@netweb later added that because Sass is widely used in Gutenberg this may be up for discussion, but likely Core will be dropping Grunt and moving to native npm scripts and @wordpress/scripts.)
This led to a discussion on IE support and graceful degradation. I suggested defining a set of rules for what is essential functionality that we need to support in IE, so we can be more confident in using shiny new tech for non-essential functionality. @michael-arestad suggested creating a ticket for that.
@michael-arestad expects that the biggest challenge post-audit will be implementing a predetermined selector format in a way that doesn’t break plugins with custom admin sections that depend on wp-admin styles.
In an effort to make tracking all contributions to the WordPress project across multiple locations easier, a new option is available when editing your WordPress.org profile that allows you to connect your GitHub account.
In recent releases, the process of collecting props for non-WordPress.org contributions (namely Gutenberg) has been highly manual and error prone, occasionally resulting in contributors not receiving proper credit. Connecting your WordPress.org and GitHub accounts will allow automatic tooling to be built which reduces the burden on release teams to maintain a credit list.
How it works
The feature uses an oAuth flow to grant a WordPress GitHub application read-only access to your GitHub account’s public information. This proves that you own both the GitHub account and the WordPress.org account and links the two accounts.
This has been available and tested for several months now, and many contributors have connected their accounts. But, because it was never officially announced, adoption has been low.
Below are some screenshots of how the process works.
1. Edit WordPress.org profile
Click “link your GitHub account” to initiate the process.
2. Authorize WordPress.org Profiles application
Grant the WordPress Profiles GitHub application read-only access to your public information.
3. Verify connection
Access can be revoked at any time on the Edit Profile screen on WordPress.org.
Huge props go out to @dd32 for implementing this feature. For more information on this feature and the ongoing effort to make collecting props easier, see Meta-#4447.
