WordPress 5.4 Field Guide

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.66.76.86.97.07.17.27.37.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.

Customizer

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:

Menus

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:

Privacy

On the 15 updates in the Privacy component, you will want to specifically note:

  • Personal Data Export now includes Session Tokens, Community Events Location and Custom User Meta.
  • Personal Data Exports now include a JSON file and a Table of Contents
  • New filters for the headers of all Privacy-related emails
  • The privacy tables are improved for a cleaner interface
  • wp_get_user_request_data() function was replaced with wp_get_user_request() for better clarity

All those changes are in this dev note:

REST API

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:

Shortcodes

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.

Widgets

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.

Other Developer Updates

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.

But Wait, There is More!

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)
  • Comments: Add “in reply to” in comment moderation email notification (#43805)
  • Embeds: Embed support has been added for TikTok (#49083) (Gutenberg#19345)
  • Embeds: Removal of CollegeHumor embed as the service doesn’t exists anymore (#48696) (Gutenberg#18591)
  • Login and Registration: Clearer information about errors in wp_login_failed (#49007)
  • Login and Registration: new parameter passed into the lostpassword_post action in retrieve_password() (#38334)
  • Networks and Sites: Site ID has been added to the newblog_notify_siteadmin filter for multisite installs (#48554)
  • Networks and Sites: switch_to_blog() and restore_current_blog() reuse switch_blog action (#49265)
  • Media: store the original URL of the attachment in the _source_url post meta value (#48164)
  • Menus: Make tabs panels more accessible for keyboard users (#49211)
  • Posts, Post Types: Use delete_posts without triggering PHP notices in every post type (#30991)
  • Post Thumbnails: Make sure get_post_thumbnail_id() returns an integer, to match the documented return value (#40096)
  • REST API: Expose all theme supports and changed permissions in /themes endpoint (#49037)
  • Site Health: Theme headers support “Requires at least” and “Requires PHP” declarations (#44592)
  • Toolbar: The Admin Bar is now loaded with wp_body_open when available (#47053)
  • Widgets: Avoid duplicate IDs in Recent Comments (#46747)

Please, test your code. Fixing issues helps you and helps millions of WordPress sites.

Props to @jeffpaul and @marybaum for contributing to this guide.

#5-4, #field-guide

Bug Scrub Schedule for 5.4

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.

  1. 1/21/2020 19:00 UTC
  2. 1/29/2020 23:00 UTC
  3. 2/7/2020 05:00 UTC (APAC-Friendly)
  4. 2/10/2020 16:00 UTC
  5. 2/18/2020 20:00 UTC
  6. 2/27/2020 23:00 UTC
  7. 3/2/2020 18:00 UTC
  8. 3/11/2020 TBD (If Necessary)
  9. 3/17/2020 TBD (If Necessary)
  10. 3/27/2020 TBD (If Necessary)
  11. 3/30/2020 TBD (If Necessary)

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.

#5-4, #bug-scrub

XML Sitemaps Meeting: March 24th, 2020

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!

Agenda: March 24th

The next meeting will be held on Tuesday, March 24 at 16.00 CET.

Today’s agenda is rather straightforward so far:

Want to add anything to the above? Please leave a comment here or reach out on Slack.

This meeting is held in the #core-sitemaps channel , to join the meeting, you’ll need an account on the Making WordPress Slack.

#agenda, #feature-plugins, #feature-projects, #xml-sitemaps

Editor Chat Agenda: 25th March 2020

Note taker: @andraganescu.

This is the agenda for the weekly editor chat scheduled for Wednesday, March 25, 2020, 14:00 UTC. This meeting is held in the #core-editor WordPress Slack channel.

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.

#agenda, #core-editor, #editor-chat

WP Notify weekly meeting suspended, call for proposals for new meeting times or new meeting hosts.

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.

#feature-notifications

#agenda

Dev chat summary, March 18, 2020

@marybaum facilitated the chat on this agenda.

Full meeting transcript on Slack

This devchat marked week 10 of the 5.4 release cycle.

Announcements

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. 🙏🏼

#5-4, #core, #feature-plugins

Updating the Coding standards for modern PHP

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.

Continue reading

#modernizewp, #codingstandards, #php, #wpcs

CSS Chat Summary: 19th March 2020

Full meeting transcript on Slack: https://wordpress.slack.com/archives/CQ7V4966Q/p1584651672176800

I (@isabel_brison) facilitated the meeting. 

CSS audit updates

  • 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. 

#core-css, #summary

Associating GitHub accounts with WordPress.org profiles

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.

WordPress.org profile with GitHub profile link highlighted.

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.

If you have not already, please take a moment to connect your GitHub account to your WordPress.org account by going to https://profiles.wordpress.org/me/profile/edit/.

Below are some screenshots of how the process works.

1. Edit WordPress.org profile

WordPress.org profile edit screen with the GitHub Username section highlighted.
Click “link your GitHub account” to initiate the process.

2. Authorize WordPress.org Profiles application

The authorization screen on GitHub for the WordPress.org Profiles application.
Grant the WordPress Profiles GitHub application read-only access to your public information.

3. Verify connection

WordPress.org profile edit screen showing a linked GitHub profile.
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.

Release Model Working Group Chat Postponed

Sorry for the very late notice, but tonight @amykamala and I are not able to host the chat.

However, if you are interested in working on it async, here are some issues that need help.

See you on April 1t (no joke!)

#release-process

Dev Chat Agenda for March 18, 2020 (5.4 Week 10)

Here is the agenda for the weekly meeting happening later today: Wednesday, March 18, 2020, at 09:00 PM UTC.

Announcements

WordPress 5.4 Release Candidate 3 landed yesterday, March 18, as scheduled.

Upcoming Releases

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.

#5-4, #agenda, #devchat

Editor chat Summary: 18 March, 2020

This post summarizes the weekly editor chat meeting (agenda here) held on Wednesday, 18th March 2020 in Slack. Moderated by @jorgefilipecosta.

Opening Remarks

WordPress 5.4 Upcoming Release

  • WordPress 5.4 RC3 was released yesterday [17 March 2020].
  • Details of the editor fixes included in the release can be found on Github.
  • Next Monday [23 March 2020] will be the package publish date for the next RC.
  • [As of 18 March 2010] there are 3 days left to merge things for WordPress 5.4 that will be tested during the RC period.
  • Todo list for WordPress 5.4 is on the Github project board.
  • 🙏The Core team are looking for folks to help with Reviews and PRs.

Gutenberg version 7.7.0

Monthly Plan / Weekly Priorities

Task Coordination Summary

Tasks that folks have been working on or that they plan to work on:

Points from the Open Floor

👀 Needs review

The following items require review and/or input: