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.
It was the first meeting for the Plugins & Themes Auto-updates feature, and this kick-off meeting was really efficient and worthwhile for the project 🚀
WP Auto-updates feature general scope
Here is the current general scope of the Feature Plugin:
Ability for website administrators to opt-in to automatic updates for plugins and themes in the related WP-Admin screens
✅ Done for plugins
🔲 Themes: needs to be ported. Slated for milestone 0.4.
Ability to enable/disable auto-updates on a plugin-by-plugin and theme-by-theme basis
✅ Done for plugins
🔲 Themes: needs to be ported. Slated for milestone 0.4.
Email notifications to send regular auto-update summaries to website administrators
🔲 Plugins: Slated for milestone 0.3.
🔲 Themes: Slated for milestone 0.4.
Hooks and constants to help developers disable or programmatically define auto-update settings
✅ Done for plugins
🔲 Themes: needs to be ported. Slated for milestone 0.4.
For the moment, the team started with plugins autoupdates, then all this work will have to be ported to Themes screen.
@audrasjb shared some screenshots of the current design of WordPress Admin screens:
Click images to open them in full size (it will opens in a new tab).
@clancy will open GitHub issues to provide some feedback on the Plugins screen’s user interface.
Work in progress
@pbiron raised an issue with a premium plugin that assumes there is no extra column on the plugins list table and add its own column with a colspan attribute. As mentioned by @clorith, this is not a bug in WP Auto-update feature plugin but rather a bug in this particular plugin. @jeffpaul proposed to add this to a Known Issues/Caveats section in readme files.
@jeffpaul also proposed to port the Features/to-do list section from readme.md into GitHub issues. @audrasjb already ported Email notifications and Themes auto-updates into issues, and @jeffpaul will take care of the remaining ones.
@jeffpaul pointed out that 10up uses two GitHub Actions to help deploy plugins to WordPress.org as well as readme/asset updates. He proposed to submit a PR to add those here and help streamline deploys to WordPress.org. For the moment, @audrasjbgenerates releases from the GitHub repository and deploy them manually on the plugin repository, using SVN. If it’s not a top priority, it would be nice to improve this workflow.
As proposed earlier in core-sitemaps meeting, @pbiron suggested to add a label to issues when something different will have to be done to the plugin code when it gets merged into core. @audrasjb stated that it would be nice to introduce this kin of labels and also to use DocsBlocks comments to point out things that will need specific implementation on WP Core. @jeffpaul proposed to use a GitHub pull request template for that.
About next development steps, @audrasjb is currently implementing email notifications. It shouldn’t be a problem given there is an useful automatic_updates_complete action to hook on.
Porting auto-updates features from Plugins to Themes will probably be a way more difficult, as there is not so much hooks in the Themes screen template. Themes in multisite is fairly straightforward, since a list table is used there, but for single sites there is no list table so what we’ve done for plugins won’t really apply. We’ll probably end up with JavaScript hacks to include the interface opt-in buttons and informations. @jeffpaul proposed to expand the focus of 5.4.x to include those hooks in the themes screen, which sounds like a perfect option right now.
@audrasjb thinks this issue is out of the feature plugin’s scope. @clorith added that if auto-updates are off by default, yes this would be out of scope for the first release, but definitely something to look into in the future. If they are on by default, this would be a blocker. @audrasjb answered that Plugins, Themes and Core (major) auto-updates are all meant to be opt-in, in the 2020 general roadmap. The team agreed to keep this issue open for the moment.
@audrasjb said Postponing updates is a great feature, but it’s not on this feature plugin scope, and not sure it’s even in Core scope. @clorith pointed out that the core solution should facilitate by providing filters and such, but not add all those options. The team agreed to keep this issue open for the moment.
Next steps
@audrasjb will focus on email notifications development and grant GitHub commit access to @pbiron.
A call for testing will be published on Make/Test once 0.2.1 is released with the PHP notices fixes.
@jeffpaul will work on improving the GitHub repository organization.
@nerrad as been kind enough to offer to share an aggregate of news relevant in the Gutenberg and general JavaScript ecosystem, to include in the summary notes for each week’s meeting.
Discussion:
There was an agreement that it’s a great idea.
The plan is to add this as an extra section in our JavaScript chat summary starting from this week.
Action items:
New agendas should be structured to include separate sections “Agenda Topics” and “News Roundup”
Note-takers should aim to include these items in the published summary notes.
@aduth added a pull request about a potential revision to our default ESLint configurations (i.e. coding standards) at https://github.com/WordPress/gutenberg/pull/20737. He just wanted to bring it to attention, since any of these sorts of coding standards changes are good to highlight. There’s been some positive feedback already on the pull request that was echoed in the chat.
@isabel_brison created a ticket https://core.trac.wordpress.org/ticket/49606 to introduce visual regression testing in the WordPress core, so we can clean up some of the old CSS with confidence. She was wondering if this type of testing has been discussed or explored at all for core or Gutenberg. Also, would there be value in adding it for Gutenberg, too?
Discussion:
There’s no visual regression testing in Gutenberg as of today, but there are parts of the tooling that could make it possible, like taking screenshots with the headless browser via Puppeteer. At least with the ticket as presented, it seems primarily focused on existing screens which may not be expected to change, and thus primarily with the aim of preventing regressions while doing CSS refactoring.
The tests themselves are minimal, but the reference images are not insignificant though and need to be updated periodically. The biggest concern is the size of the assets that would have to be maintained and how to ensure they don’t pollute repositories with source code.
There is a pull request that explores primitive UI components that can be used both in native mobile apps and in the browser: https://github.com/WordPress/gutenberg/pull/19104. There was no specific discussion item attached to this, but it was requested that anyone interested take a look and provide any feedback they have to drive further development.
News roundup
A few links to Gutenberg and JavaScript related news (curated by @nerrad).
The March edition of What’s next in Gutenberg is up. Focuses are: Block content area, global styles, patterns, and general tightening up of previous work.
A really interesting library of templates has been launched by Gutenberg Hub. Could this help inform some of the patterns work various folks have been looking into? What’s really cool about this library is that the initial launch only uses core Blocks (except for the contact forms)! You can read the wpTavern’s take on this library here.
General Block Editor API Updates include: Meta attribute sources deprecated, Shortcode transforms configuration can include an isMatch function, AsyncModeProvider API, custom media upload handler as a setting, easier drag and drop, rich text won’t set focus when applying a format, a new guide component, and deprecation of @wordpress/nux.
With WordPress 5.4 around the corner, Gutenberg 7.7 is another exciting release. It introduces patterns and the first iteration of a new block UI design which aims to synthetize the learnings from these past couple years of Gutenberg being out in the wild.
New Block UI
After more than a year from its first production release, the community pushed the boundaries of the editor further than we’d have expected. The number of third-party blocks exploded and millions of users are interacting with the editor in different ways. This led to a refresh of the Block UI to apply some of the lessons learned in the meantime.
The redesign includes:
A simpler Block Toolbar.
Better UI color contrast.
Consistent focus styles.
Redesigned icons.
Grid-based spacing and sizes.
And more.
As with any feature in the editor, this is the initial release and there’s still more work planned to bring more consistency in the remaining UI elements: sidebar panels, drop-down menus, etc.
Block Patterns
While the editor has a rich set of built-in blocks, it is sometimes challenging for users to compose these blocks together in order to achieve the best designs for their pages. And as we accelerate towards Full Site Editing, this becomes an important challenge to solve.
Different existing community-provided solutions have addressed this by providing rich sets of templates/layout that are ready to use and prevent that dreaded “white page syndrome”. There is a need to bring some consistency and coherence to these features. Gutenberg 7.7 introduces Block Patterns: predefined block layouts, ready to insert and tweak to address that problem.
As a first iteration, the Block Patterns UI has been added as a sidebar plugin from where you can pick and insert the patterns. This is considered an MVP and the UI is expected to evolve over the next releases.
As a start, the plugin comes with a small limited set of patterns. The list will ultimately grow and be opened to third-party authors.
7.7 🇵🇭
Features
Add the initial version of the Patterns UI as a sidebar plugin (this is not the final interface and work is in progress to integrate with the main block inserter). 20354, 20715.
Plugin: Bump minimum WordPress version to 5.3 20628
@wordrpess/priority-queue: Fix for environments that don’t have window defined. 20486
Update jest configuration to only ignore tests from /wordpress/ as a subdirectory 20420
Performance Benchmark
The following benchmark compares performance for a particularly sizeable post (~ 36000 words, ~ 1000 blocks) over the last releases. Such a large post isn’t representative of the average editing experience but is adequate for spotting variations in performance.
I recently commented on Twitter that I have a stretch goal of having a release squad that is all women by the end of 2020. With the work I’ve been doing to prepare for my upcoming sabbatical, I’ve been giving a lot of thought about how to do this and what I hope it accomplishes.
What’s the Goal?
The primary goal of any release cycle is to ship a stable and enhanced version of the WordPress CMS, but for the past year or so we’ve also been sharing the procedural work with a team of people. I affectionately refer to them as the release squad.
My hope is that with a release squad comprised entirely of people who identify as women, we’ll be able to increase the number women who have that experience and (hopefully) become returning contributors to Core and elsewhere. This doesn’t mean the release will only contain contributions from women. And if our current squad training process is any indication, it also doesn’t mean that we’re asking a squad to show up and do this without support.
What’s the Plan?
I have a list of about 75 women who raised their hands to participate in this release squad. I think that we can use the current squad training process (ride along, navigate while someone drives, drive while someone navigates) to progressively level up everyone’s skills. Stepping away at any time is an option as long as it’s communicated. 🙂
So far, this is the broad idea for how we will get there:
Prepare and Plan
Make sure the timing works for anyone who already volunteered.
Determine current skills and team involvement.
Reach out proactively to gather additional people where I don’t have quite enough.
Gather groups and group mentors.
Ride Along on Release 5.5
Join triage sessions, meetings, etc and ask every question.
Navigate Release 5.5.x
Collaborate with the 5.5 release squad to navigate a point release and ask every question.
Drive Release 5.6
Drive the release while collaborating with some long-time women contributors.
How Can You Help?
The preparation for this will be a big undertaking, but probably just as much training effort as any other release squad I’ve worked with. It’s still a stretch goal, but I figure the best way to get there is to get started. I’m interested to hear from:
Anyone who wants to be a mentor or part of the release process.
Anyone who has a little extra time to help me with the preparation.
Anyone who has questions about how this will work. 🙂
A lot has happened since last week’s meeting for the XML Sitemaps feature project. Here’s a quick rundown of what we’ve discussed & did, as well as a brief agenda for today’s meeting.
Meeting Recap: March 3rd
For reference, please check out last week’s agenda post:
Disabling sitemaps for private sites Mentioned the currently open PR and how it could be used to kill two birds with one stone by making that process filterable; thus making it easier for plugins to disable the sitemaps feature. Current status: needs tests
Prefixing sitemap URLs The main PR for this change has been merged, a new issue has been opened for @kraftbj to handle 404 requests.
SimpleXML dependency We went over potential alternatives to this extension, but ultimately settled on sticking with the status quo as initial feedback indicated a rather wide availability of SimpleXML. We then discussed how we should gracefully handle the unavailability of said extension and decided on using wp_die to output a nicely formatted error message in XML with HTTP status 501 (“Not implemented”). Current status: merged!
@joemcgill proposed looking into how to best transition the code base to something more in line with WordPress core. Something that we can discuss in a future meeting, once the plugin is more stable.
This is the agenda for the weekly editor chat scheduled for 2020-03-11 14:00 UTC. This meeting is held in the #core-editor WordPress Slack channel.
WordPress 5.4 Upcoming Release
Gutenberg version 7.7.0
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.
@jorgefilipecosta gave a big thank you to everyone that helped the big effort on writting the editor dev notes.
@jorgefilipecosta ended the topic by sharing the following information:
For the next RC currently, we have three issues that should be fixed. Two of the issues have a PR that needs review. Another one does not have a PR yet. The status of these tasks can be checked on https://github.com/WordPress/gutenberg/projects/39
Is reviewing and testing the new PR that provides menu endpoints in Gutenberg # https://github.com/WordPress/gutenberg/pull/20292. It is a big PR and while it is tested in the feature plugin any extra eyes are welcome!
Is experimenting with WebGL blocks right now and working around the constraints. Is trying to get people’s thoughts/opinions on a Gutenberg feature request he has related to rendering in the background and providing a single requestAnimationFrame render loop for multiple blocks https://github.com/WordPress/gutenberg/issues/20483.
Open floor
Custom text color format
@paaljoachim brought to the discussion the fact that the text color may or may not be a main format.
@jorgefilipecosta clarified that the fact that the text color appears on the main formats when a color is selected and disappears from the main formats if no color is selected is not a bug. It was an implemented behavior to avoid too many main formats but at the same time give relevance to the format if color is chosen. We may discuss this behavior in an issue and it may make sense to change.
