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.
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.
The current major is 5.4; please keep testing for all the bugs. At the same time, trunk has branched to 5.5 as of RC1. That means 5.5 is officially in alpha.
Final release is March 31.
Components Check-in
News from components
Components that need help
Cross-component collaboration
Open Floor
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.
Remove update time text after manual update – PR 43
Ensure “Automatic Updates” column is not added if no content would be output in the column – PR 57
Specific messages for delayed or disabled cron events – PR 58
Prevent mis-match between count in Auto-updates Enabled view and the number of plugins displayed for that view by applying ‘all_plugins’ filter before computing that count. – PR 59
Thanks @pbiron for his invaluable help on version 0.3.
@audrasjb shared a screenshot with an example of email notification:
Please feel free to propose string changes to this first implementation of email notifications.
Version 0.4.0 will focus on backporting every auto-updates features to Themes.@audrasjb to merge this pull request as a first step for the work on themes support. Then, the idea is to open pull requests for each function/feature to be backported, so it’s easier to track progress on themes support.
@bookdude13 asked whether it’s better to open up issues to break up the work on the themes port, or to directly address them with pull requests.
@audrasjb will open an issue to list all the functions/feature that need proper backport and to track the team’s progression.
There is also a few background tasks opened by @jeffpaul concerning the GitHub repository.
Concerning Email notifications, @joostdevalk proposed to add links to the plugins changelog in those emails. @pbiron answered that it might be hard for plugins/themes not in the WordPress.org repo. @joostdevalk proposed to make it filterable. @audrasjb proposed to make the notification entirely filterable. @joostdevalk felt concerned about plugins that would override the email even when multiple plugins are updated at once.
@afragen proposed to use a filter that could be specific for each, like for example: apply_filters( 'wp_autoupdates_email', $text, $slug )
This item will be discussed again during the next team meeting.
@pbiron wanted to discuss a specific pull request. It proposes to add filters to control whether the Enable/Disable buttons appear in the UI for a given plugin. @pbiron and @audrasjb agreed that having a filter that is specific to the UI is not the way to go and it is to be filterable then the existing auto_update_plugin hook should be used. For now, the pull request will stay open for further discussion.
Next meeting is planned on Tuesday March 24, 2020 at 18:00 UTC and will take place on #core-auto-updates Slack channel.
@since x.x.x: Should always be 3-digit (e.g. @since 3.6.0).
This is in contrast to the PHP documentation standards, which include guidelines around using @since as a changelog:
If significant changes have been made to a function, hook, class, or method, additional @since tags, versions, and descriptions should be added to provide a changelog for that function.
Proposal: Incorporate some adaptation of the PHP since changelog guidelines into the JavaScript inline documentation standards.
Discussion Points:
@nerrad asks if this could be used to pull documentation automatically from the source code. This is quite possible, and is likely exactly what is done with the PHP source code documentation (example documentation and source).
Action Items:
Update the JS documentation standards, assuming there is no opposition presented in the coming days.
Disable the JSDoc since format validation for Gutenberg in the related changelog (already done)
News Roundup
This roundup contains a few links for Gutenberg and JavaScript related news curated (and commented on) by @nerrad.
Gutenberg 7.7 was released (and shortly thereafter 7.7.1). Highlights in this release are: the new block ui (otherwise known as “G2”) and the initial version of the block patterns ui.
Outside of normal Gutenberg and JS news, but I thought it worth highlighting – All-women release squad. I’m so excited about this!
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.
