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

Core Team Chat Changes for Daylight Savings Time

As @audrasjb noted in last night’s Dev Chat summary, three meetings will start one hour earlier, beginning next Wednesday, April 15.

That’s because all the countries who switch to Daylight time have done that. The US is traditionally the beginning of a four-week process that ends early in April. The process reverses in the fall.

The Core devchat will start at 20:00 UTC, or 8 pm UTC, on Wednesdays.

That in turn will push the New Contributor meeting and the Release Model Working Group meeting, which alternate Wednesdays immediately beforehand, to 19:00 UTC, or 7:00 pm UTC.

The Release Model Working Group will meet on April 15, and the New Contributor meeting will see you on April 22.

So mark your calendar accordingly, and the teams hope to see you there!

In the meantime, if you celebrate a spring holiday, please accept the community’s wishes for a happy, healthy and safe occasion.

#devchat, #meeting-changes

CSS Chat Agenda: 9nd April…

CSS Chat Agenda: 9nd April 2020

This is the agenda for the upcoming CSS meeting scheduled for Thursday, April 9, 2020, 5:00 PM EDT.

This meeting will be held in the #core-css channel in the Making WordPress Slack.

If there’s any topic you’d like to discuss, please leave a comment below!

  • CSS audit status update
  • Open floor

#agenda, #core-css

Devchat meeting summary – April 8, 2020

@audrasjb facilitated the chat on this agenda.

Full meeting transcript on Slack

Announcements

Upcoming Releases

Next minor release: WP 5.4.1

While there is no release planning for the moment, there is already 12 tickets in the milestone.

2 tickets are labelled with major severity. It will probably lead to a point release in few weeks.

@whyisjake will run a first bug scrub for WP 5.4.1 on Thursday April 9, 2020 at 20:00 UTC.

@marybaum volunteered to run another bug scrub on Friday.

Next major release: WP 5.5

There is currently 27 tickets with early keyword in the milestone. Those tickets need to be merged as soon as possible.

@davidbaumwald will run a first bug scrub for WP 5.5 on Tuesday April 14, 2020 at 19:00 UTC.

Component maintainers updates

@afragen shared a number of tickets for theme compatibility that still need eyes and are marked early. All have working patches and need further testing.

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

The next meeting will be held on Wednesday April 15, 2020 at 20:00 UTC.

@marybaum is going to publish a specific announcement about this adjustment.

#5-4-1, #5-4, #5-5, #dev-chat, #devchat

WordPress 5.5: Call for Tickets

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!

#5-5

Lazy-loading of images is in core

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.

It would also be very beneficial to the users if the plugins that implement lazy-loading are updated to utilize the new Core functionality and filters, and to use the new loading HTML attribute. Please see https://html.spec.whatwg.org/multipage/embedded-content.html#attr-img-loading and https://html.spec.whatwg.org/multipage/urls-and-fetching.html#lazy-loading-attributes.

A dev note with more details on the implementation and how to customize the behavior will be published closer to the WordPress 5.5 release.

#feature-lazyloading

Auto-updates feature meeting summary: April 7th, 2020

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, the Feature Plugin is developed on GitHub and is available for testing on WordPress.org plugins repository.

Current status of the project – version 0.4 🌹

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.

Version 0.5 scope and timeline

For the moment, there are 5 PRs merged into milestone 0.5.

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.

For reference, see issue #63 and pull request #66.

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

#auto-update, #feature-plugins, #feature-projects, #feature-autoupdates

Editor chat summary: 8 April 2020

This post summarizes the latest weekly Editor meeting, held in the #core-editor Slack channel, on Wednesday, April 8, 2020, 14:00 UTC. These meetings coordinate collaboration in the development evolution of the Gutenberg project. You can find today’s agenda here.

First an update on Gutenberg 7.9 which was pushed one week. Progress has been good so far and release is on track for next week

WordPress 5.4 was released last week. Issue/PR’s are being kept track of using “Backport to WP Core” label. A 5.4.1 release is not scheduled yet.

Monthly Plan 

It’s early in the month, but the plan looks to be on a good track. The priorities are still the same though and available here 

Task Coordination

@isabel_brison

  • working on Navigation Block-related tasks, I realized that currently submenus in that block are almost unusable on mobile devices. 
  • I have created PR  21471 to fix them.

@nosolosw

  • I’ve been mostly helping Riad with the refactor of some block properties related to styles, including font-size for paragraph and heading.
  • Pushed a bit to the target block selectors for Global Styles proposal (still work to do).

@youknowriad

  • 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

@nfmohit

  • I’m working on adding a vertical style to the Buttons block.
  • PR 20160

@brentswisher

  • I’ve been looking into ways to make Storybook easier to work with, comments/opinions appreciated here
  • Continuing to add stories for missing components
  • Follow up on some old issues/PR’s that have resurfaced

@andraganescu

  • still working on the experimental navigation screen

@pbrocks

  • Reviewed some PRs this past week

@gziolo

  • I’m working on Jest, JSDom, Babel and ESLint upgrades for Gutenberg contributors and wordpress/scripts users 

@itsjonq

  • I’m continuing work on Design Tools
  • Focused specifically on improving the Cover block.
  • I have a PR for inner content alignment
  • Currently focusing on adding padding support!

@michaelarestad 

  • prototype to connect the various designs/functions around Full Site Editing and an iteration of multi-entity saving

@kirilzh

PRs and Issues for Review and Comments

  • PR 20954 Scheduled post does not show correct url on preview
  • PR 21440 Copy/cut input values copying entire block/removing block
    PR 21359 Latest Posts: Fix selected category on existing blocks
  • 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.
  • PR 21410 Scheduled posts display the correct url

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.

PR 19436 Selection Behaviors with Reusable Blocks

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.

Dev Chat Agenda for April 8, 2020

Here is the agenda for the weekly meeting happening later today: Wednesday April 8, 2020 at 21:00 UTC.

Announcements

If anyone has any announcement to make, now is the time!

Highlighted blog posts

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

JavaScript Chat Summary: April 7, 2020

Below is a summary of the discussion from this week’s JavaScript chat (agenda, Slack Transcript).

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

Consent API

(Slack conversation)

Context: https://github.com/rlankhorst/wp-consent-level-api/issues/50

Feature Proposal: https://make.wordpress.org/core/2020/04/01/feature-plugin-proposal-wp-consent-api/

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.

#core-js, #javascript

Editor Chat Agenda: Wednesday 8 April, 2020

Note taker and facilitator: @itsjusteileen

This is the agenda for the weekly editor chat scheduled for Wednesday, 8 April, 2020, 10:00 AM EDT / 2:00 PM UTC

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.

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