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)
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
Below is a summary of the discussion from this week’s JavaScript chat (agenda, Slack Transcript). Many thanks to @cbravobernal for compiling these notes!
Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.
The types (declaration files) will be published with the packages, so folks using the packages via npm will have access without doing anything else.
The type generation is built into the existing package build/publish flow, so things should remain largely the same from the perspective of Gutenberg development (hopefully with better information in our IDEs!)
npm run build:package-types is the script that generates them.
Write a blog post to share the info about the progress on types support and maybe post separately on the all parallel efforts that people might get involved in the project: TypeScript, Storybook, unit tests, etc
There is a small discussion about seeing if it is necessary to discourage or not jsx files. Noticing that changes to accept jsx are quite simple. And are even accepted in some code already. There are different opinions, so the team prefer to continue the discussion.
@gziolo had issues upgrading Jest with the last version. See pull request. Asks if is it a good reason to refactor them to use the React Testing Library?
@aduth comments that is Enzyme related issue. That expects a DOM to exist.
Airbnb transferred the project to the community. Seems that everyone is going to switch away from Enzyme.
Also they comment that Jest, Babel and Puppeteer should be upgraded, and would be nice to have some strategya arount all that. The project seems to have too many dependencies.
Action:
No action defined.
News Roundup
This roundup contains a few links for Gutenberg and JavaScript related news curated (and commented on) by @nerrad.
Riad has published the April edition of “What’s next in Gutenberg?”. Focuses this month are: Full site editing, global styles, patterns and inserter UI, an updated Navigation screen, and more refining of the editor interface.
In order to prepare a retrospective post, I would like to ask everyone to leave some comments below with things they would like to bring up. To help, here are some questions to ask yourself:
What should WordPress start doing as a part of the development process?
What should WordPress stop doing as a part of the development process?
What should WordPress continue doing as a part of the development process?
Please note that I am looking for feedback specifically on the development and release process.
Please share your thoughts in the comments below!
If you rather not give your feedback in a public space, please reach out to me (@francina) or @davidbaumwald, in Slack. We are available to collect your feedback in a safe space, with no judgement and use it in the retrospective in an anonymous form.
Remember when commenting to keep the discussion professional and focused on ways the process of creating WordPress is either already working great or can be improved.
The a11y team had a look at the audit tickets at their weekly meeting and had a few recommendations.
Based on a11y team feedback, we agreed to add notes to the audit on any CSS properties we find that are unhelpful for accessibility.
Open Floor
@joyously requested we add a channel topic to #core-css, with the time of our weekly meeting, which we did.
@joyously asked if the audit would include editor CSS, or only wp-admin pages. The current audit includes only wp-admin pages, but there was agreement on auditing both the editor and the default themes CSS at a later stage.
That was all for this week!
Next week @notlaura will be taking over the running of this meeting, due to daylight savings changes.
At the moment, those events don’t show up in the News & Events widget on the dashboard, because they don’t have a physical location. The widget was originally designed to show the user local events, because cultivating local, in-person bonds is an essential element of our community’s success.
Online events aren’t being intentionally kept out of the widget; it’s just an unforeseen side-effect of the temporary shift to online events. Online meetup events still appear in the widget, because in the absence of an explicit event location, the Meetup.com API falls back to the location of the group.
Questions
Should online WordCamps show up in the widget?
If so, who should they be shown to? Here are a few potential criteria:
The same people who would have seen the in-person event. i.e., anyone within a 400km radius of the venue.
Everyone within the same country. Would this apply equally to countries that host a small number of camps, and those that host a large number? Would it apply equally to countries that often see people from neighboring countries traveling to attend the event, and to countries where that is not common?
Everyone within an increased radius, e.g., 600km. If so, what would be the best distance?
Everyone within the same timezone, plus-or-minus a few hours.
Everyone who speaks the same language— or locale? — as the host city.
A combination of the above? Some other criteria entirely?
Should the timezone and/or language of the event be displayed in the dashboard?
