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)
@audrasjb pointed out that the Auto-updates team needs a cross-team discussion about wording and specifically concerning the action links text labels. Design and Accessibility teams could help, and of course everyone interested. Design & Wording validation is the main goal for the next version of the feature plugin.
@garrett-eclipse shared that the Privacy team has a multisite focus in 5.5 so any people from Network/multisite component is welcome to assist.
Daylight saving time: devchat meeting time change
As Daylight saving time already started for every countries/locales on our planet 🌏 the devchat meeting time will be adjusted from 21:00 UTC to 20:00 UTC.
With 5.4 released, let’s officially kick-off 5.5! As we do with each release, we want to fix bugs, add new tools and make WordPress the best user experience. The blocker editor (and full site editing) are still at the top of the WordPress goals list, but what other tickets do you think need some attention in this release cycle?
Share Your Feedback!
What do you want to see included in 5.5?
What are current UX pain points?
What features can we add or iterate on?
Component Maintainers: what tickets of yours do you think will be ready to ship in 5.5 and need some review/feedback/approval/etc?
Note: Adding your ticket here won’t necessarily guarantee inclusion. But no one can fix things they can’t see, so bravely share your thoughts!
As planned, the patch for adding loading attribute to img tags is now committed to core (see #44427).
Based on preliminary testing there seem to be no conflicts with most plugins that implement lazy-loading for images. Nevertheless the authors of these plugins are strongly advised to test them in trunk (WordPress 5.5-alpha) and confirm their plugins work as expected.
These are the weekly notes for the WP Auto-updates team meeting that happened on Tuesday April 7th, 2020, based on this agenda. You can read the full transcript on the core-auto-updates Slack channel.
As a reminder, version 0.4 was released one week ago and contains all the core functionalities of the project. The team opened a call for testers on Make/Tests.
The main goal of version 0.5 is to iterate on design and wording. There is a bunch of design focused issues, but the idea is to iterate on links colors and wording first.
All the attendees think all the links should be blue and text should be black. Indeed, red links are used for destructive actions in WordPress core, and it’s not relevant for auto-updates disabling. So let’s get rid of red links and green “Auto-updates enabled”. Let’s just use blue for links and black for text. This change will be part of 0.5.
About wording, @audrasjb wanted to point out that “auto-update” (don’t forget the hyphen) is the official wording for the feature in WordPress as it has been validated ahead of the Feature Plugin with WP project leads.
@pbiron pointed out his concerns about removing any filters on the plugins screens, especially the “Auto-update disabled” filter, as it’s really useful to see what plugins are not auto-updated. The team agreed that this filter is not going to be removed.
How to avoid conflicts with third party plugins?
@ronalfy pointed out, from a third-party standpoint, that if a plugin uses a custom option for storing updates, it’d be nice to be able to sync the two through actions and filters. So if WordPress enables an auto-update, the plugin can hook into that action and update their own list accordingly. The same would be useful for filters when retrieving options so the plugin could theoretically merge the two. Ideally third-parties could just use WordPress options, but there’s backwards compatibility issues there.
@timothyblynjacobs added that being able to add bits to the auto update column itself would be useful as well.
Next steps:
Add an action hook on auto-update enabling and disabling for each theme/plugin.
Add a hook to filter the auto-update column content itself.
Discussion/decision concerning AJAX handling in the Feature Plugin
While this is not a top priority, it’s a nice to have. The team agreed to target version 0.6 for this enhancement.
Discussion about the labels used for enabling/disabling auto-updates
There is a proposal to change the current action links labels.
@pbiron and @audrasjb pointed out that on/off and “plain” Enable/Disable (without “auto-updates”) could be too easily confused with Activate/Deactivate (even with them being in the Automatic Updates column).
There is definitely a need for a cross-team discussion about the best wording for those links.
Meeting time and Daylight Saving Time
The team agreed to move the meeting time from 18:00 UTC to 17:00 to follow Daylight Saving Time.
I have been mostly focused on the Color and gradient support for different blocks and consolidating the way we support these in different blocks. (Also thinking in relation to Global styles)
I’m planning to do more work on the inserter and patterns UI on the next days
Issue 21391 Comments and review for the Drag & Drop feature
Issue 11681 Looking for input into possible changes for block templates
Open Floor
Global Styles and Theme/Block Color Palettes
There seems to be a lot of (potential) crossover between Global Styles and Theme/Block Color Palettes. Is this something there’s been discussion about?
The focus currently has been on the foundational pieces for Global Styles, but that’s definitely something that we should look at shortly. There may be the possibility to use theme.json to define the palettes and the Global styles UI to potentially allow editing them/choosing colors based on them.
Possible Additions for 5.4.1
PR 17413 Add Block Transform to transform Embed blocks into Paragraph blocks.
Today embeds do not function really well. There are cumbersome work arounds if a link wants to embed and one does not want to embed it, as in add a dot then the text link. Or add some text and then a link. Then remove the text again etc. The issue could use additional feedback.
Dynamic content in HTML files from Block-Based Themes Issue 20966
One potentially native solution would be to allow some php in these templates but more thought is needed.
Adding skip to content link and aria labels for FSE An issue needs to be added to Github to add skip link support for theme authors in FSE. Skip links are one of the most fundamental things for a11y on a site which needs to be hidden to normal users and only visible on keyboard-navigation (tabbing) and screen-readers. The link needs to be the 1st thing on a page, and it needs to link to the main content of the site.
All theme developers add a skip link. It usually points to the <main> element of the page (which 99% of the time has id=”main”). If the template in FSE contains a “content” block, then we could add an ID to it and automatically add the skip-link. If there is no content block, then the skip-link would point to the loop block. If there is no loop-block either, then make an educated guess and point to the 1st title or p block. This is a possible solution but more discussion should be directed to a GitHub issue.
PR 21410 Is it possible to generate the permalink as the link property of a scheduled post in the REST API, as is the case for published posts now? The answer might be related to the fact that the slug might be already used by the time the post gets published but this is best asked in the #core-restapi channel.
This relates to some funky selection behaviors with reusable blocks, or really any instance of nested Block Editors, where you can have blocks selected in the upper and lower editors at once. RichText buttons are absorbed into the parent, etc, When experimenting with nested block editors to persist block data to unconventional data stores this problem arises quite a bit.
Nested block editors may not be a great idea, but potential options could be:
The nested block editor should live in a modal or a separate page (link)
Use the controlled “InnerBlocks” approach we’re experimenting for template parts (and multi-entity save flow). This approach is not stable 100% yet but seems promising.
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.
Discussion: What is the ideal JavaScript interface for accessing, updating, and responding to changes in consent? In what ways could we leverage the existing data module?
Discussion Points:
Is data module supported on sites running Classic Editor plugin? Is it otherwise tied to the block editor?
While it is developed in the Gutenberg repository, it’s intended to be general-purpose to support a variety of use-cases.
For example, WooCommerce plugin is using the data module outside of the editor context.
A primary value of the data module is API consistency in retrieving and updating data.
There is a need to support expiration as part of the requirements of the Consent API.
@nerrad has done some experimentation around this and would be happy to help contribute to the discussion.
@youknowriad shared a code example for how a basic consent implementation could be achieved using the data module.
There could still be abstractions on top of the data module.
For example, the blocks module uses the data module internally, but still exposes its public API as wp.blocks.registerBlockType, etc.
Ideally these would still follow the convention of groupings under the wp global (wp.consent).
Another advantage of the data API is that it provides future-proofing if blocks or future UIs are built with the Consent API in mind.
There’s a general desire to develop new APIs as following consistent and established patterns.
There may need to be enhancements to the data module in order for it to be most useful:
Subscribing to changes in a specific store value is currently cumbersome.
Expiration.
Persistent storage using cookies.
The current data module or persistence implementation can support this, but it may still need further enhancements so as not to break expectations that preferences may still need to save to localStorage for the near future.
This meeting is held in the #core-editor channel in the Making WordPress Slack.
Gutenberg 7.9 Update Planning for WordPress 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.
Things that have been discussed in the last two meetings:
Plugin Conflicts (#146) We discussed the rewrite rules conflicts that might currently happen with certain plugins. A consensus hasn’t been reached so far, but it could actually be declared a non-issue: if plugin A overrides the default sitemap functionality, that might be intended behavior. Current status: needs decision.
Rewrite Rules (#147) A change was proposed to improve the way rewrite rules are registered for sitemaps. This would avoid having to flush rewrite rules when custom providers are added. Current status: needs contributors.
Last modified date (#145) The PR to remove all traces of lastmod has been updated to include documentation. Current status: needs reviews.
Filterable query args #137 has been closed in anticipation of an improved solution to filter query arguments. Current status: needs PR.
Private sites (#138) Current status: PR needs some work
Roadmap WordPress 5.5 is ought to be released in August. We need to continue working on the feature plugin so we have something merge-able in May or June. The tentative roadmap would be:
Fix remaining big issues – April
Refactor code to be closer to WP core standards, add safeguards so nothing breaks after merge – April
