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 16: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

Block Collections

Collections allow specific block types to be grouped together for added visibility in the editor’s Inserter menu, regardless of their categories. For instance, a plugin such as CoBlocks may register a Map block of category Widgets and a Post Carousel block of category Layout. By registering a collection for the coblocks namespace, these blocks will appear in the Inserter under their respective categories but also grouped under a CoBlocks collection.

The Block Collections API thus aims to improve the relationship of block discovery between users and plugin authors without compromising the semantics of block types, notably around categories (e.g. formatting, layout, widget, embed).

registerBlockCollection( 'coblocks', {
	title: 'CoBlocks',
	icon: brandAssets.categoryIcon,
} );

#5-4, #block-editor, #dev-notes

Introduce block variations API

Just as you can declare a block’s style variations when registering a block, a block type can define block variations the user can pick from. The difference is that, beyond changing the look, this field offers a way to apply initial custom attributes and inner blocks at the point of insertion.

By default, all variations will show up in the Inserter in addition to the regular block-type item. But setting the isDefault flag for any of the listed variations will override the regular block type in the Inserter.

variations: [
    {
        name: 'wordpress',
        isDefault: true,
        title: __( 'WordPress' ),
        description: __( 'Code is poetry!' ),
        icon: WordPressIcon,
        attributes: { service: 'wordpress' },
    },
    {
        name: 'google',
        title: __( 'Google' ),
        icon: GoogleIcon,
        attributes: { service: 'google' },
    },
    {
        name: 'twitter',
        title: __( 'Twitter' ),
        icon: TwitterIcon,
        attributes: { service: 'twitter' },
    },
],

An object describing a variation defined for the block type can contain these fields:

  • name (type string) – The unique and machine-readable name.
  • title (type string) – A human-readable variation title.
  • description (optional, type string) – A detailed variation description.
  • icon (optional, type String | Object) – An icon helping to visualize the variation. It can have the same shape as the block type.
  • isDefault (optional, type boolean) – Indicates whether the current variation is the default one. Defaults to false.
  • attributes (optional, type Object) – Values that override block attributes.
  • innerBlocks (optional, type Array[]) – Initial configuration of nested blocks.
  • example (optional, type Object) – Example provides structured data for the block preview. You can set to undefined to disable the preview shown for the block type.
  • scope (optional, type String[]) – the list of scopes where the variation is applicable. When not provided, it assumes all available scopes. Available options: block, inserter.

#5-4, #block-editor, #dev-notes

New or Updated Blocks in WordPress 5.4

Social Icons Block

This new block lets users link to social media and other popular websites by using those sites’ logos. Initially called Social Links, Social Icons were an experimental feature in Gutenberg 6.5 but held out of WordPress 5.3. Since then, the Block Variations API has progressed to the point that Social Icons in Gutenberg 7.5 are much simpler and more stable – and ready for merge in WordPress 5.4.

This reimplementation is a breaking change in the way Social Icons are saved (see details). Only sites that have run the Gutenberg plugin since September are potentially concerned. 

In WordPress 5.4, the core block editor will not recognize any Social Icons blocks built before Gutenberg 7.5.

There are two ways to deal with this:

  • (Recommended method) Manually migrate any content with old Social Icons. Here’s how: load a post in the block editor (Gutenberg 7.5 or higher) and save it. The block editor will automatically update its contents. 
  • Keep the Gutenberg plugin installed after upgrading to WordPress 5.4. The plugin will give you manual backwards compatibility for the old Social Icons.

Buttons Block

This new block is a collection of buttons, because authors often need to use several at a time (for instance: download and read more buttons).

The buttons block shows each button as an individual button-block child of the Buttons block. You won’t be able to insert a button block outside Buttons, but your existing button blocks will work the way they always have.

In case you were using the button block as part of a template or a system that automatically inserted a button block, you’ll want to use the Buttons block with a nested button instead.

Plus, here’s some good news: you won’t need to migrate your existing button blocks. They’ll just work — again, as they always have.

#5-4, #block-editor, #dev-notes

WP Notify Meeting Recap – February 24 2020

This is a recap of the WP Notify meeting held on Monday, February 24, 2020, 14:00 UTC. You can read the full meeting discussion here in Slack.

We focused on the next sections of the requirements document, Section 3 “Current Status”, and Section 4 “Project Goals”.

Section 3. Current Status

  • Finalized description of existing API features and limitations

Section 4. Project Goals

  • We continue refining the definitions of our MVP (minimum viable product) a.k.a. Version 1.0
  • We outlined important research the project should include
  • We noted importance of retaining backwards compatibility of notifications handling

At the close of the meeting, @hrmervin posed the question of how/if Gutenberg methods of notification handling can influence this project, either in short term or long term. 

Next Slack Meeting

Join us next week, where we’ll continue the discussion on the project goals, and system feature requirements. 

📅 Monday, March 2 @ 14:00 UTC

#admin, #feature-notifications, #notifications

Devchat summary: February 26, 2020

@francina facilitated the chat on this agenda.

@valentinbora took care of publishing the meeting summary with special thanks to @amykamala, @audrasjb, @Cenay and @marybaum.

Full Meeting transcript on Slack

This devchat marked week 7 of the 5.4 release cycle.

Announcements

Upcoming Releases

Release Candidate 1, scheduled for March 3rd (read more about the WordPress 5.4 Development Cycle)

WordPress Release Cycle

For background, please read:

@johnbillion got to the heart of the matter: should beta be for fixing bugs that predate the ones introduced during alpha?

@jeffpaul shared his experience since version 4.7: beta is for any bugs, but the release candidate is for regressions only, even though the handbook doesn’t specifically point one way or the other.

@johnbillion liked the idea that beta is for every bug, as long as it’s in the milestone. But he noted that could make things tough in shorter release cycles.

@jeffpaul pointed out that avoiding committing non-regression bugs during beta means Beta and RC wouldn’t be as clearly different from each other as they are now. Potentially, they could merge into a single term.

@johnbillion averred that bugs could still get fixed in beta, but RC should be the point where the Core team is happy to release.

@joemcgill confirmed the current release cadence is set to assume that bug fixes of all types happen during the beta period (with digression from committers about what is safe to commit).

@joemcgill @johnbillion @azaozz all liked the idea of branching earlier in the cycle — for instance, at beta 1 — so people can keep working in trunk, and @sergey confirmed things typically go pretty smoothly on that end. He also favors branching as soon as the current milestone is empty.

per @johnbillion, @matt has, in the past, preferred to keep focus on the current release. 

@joemcgill stressed that the core team needs more clarity on what types of fixes are appropriate to commit to the 5.4 release, pointing out that the discussion in chat echoes this proposal to review historical practices to improve the project and potentially speed up release cycles.

@francina referred the group to the Release Model Working Group Chat Summary: February 19th, 2020 for the latest on that proposal.

@joemcgill and @francina — with other voices chiming in from the group — confirmed that 5.4 will continue as planned, with no changes. Any changes the working group comes up with will be effective no sooner than with the 5.5 cycle.

Components Check-in

  • News from components
  • Components up for adoption (Filesystem API and Rewrite Rules)
  • Components that need help
  • Cross component collaboration

@francina proposed a change to the Components Check-in. 

Up to now it’s typically fallen towards the end of the chat, so it feels rushed and rarely leaves enough time to dig into topics the group might bring up. She offers two options:

  1. Schedule a weekly post in Make, where maintainers can leave a status update, like the one for Community deputies;
  2. Adopt a Slackbot that, once a week, asks maintainers for a status update. 

@francina also proposed that those updates — and other communications — live in a new #component-maintainers Slack channel. Core is getting very busy with automated updates like Trac and Travis bots, plus RSS.

@valentinbora observed he hasn’t seen many check-ins in past meetings. @francina surmised that maintainers might not have time [to meet], or that time zones and other commitments [could be sources of conflict].

@francina and @valentinbora agreed that going async [communicating asynchronously] could help.

@cenay was in favor of the Slackbot option.

Action items

  • @francina to collect all the different info streams about the development cycle, offer a window to comment and update documentation;
  • @audrasjb to get all dev notes by the end of the week and publish the Field Guide before RC1.

Next Meeting

Meetings for #devchat take place weekly in the #core channel. The next meeting is Wednesday, March 4, 2020, 21:00 UTC.

#5-4, #5-4-release-cycle, #component-maintainers, #core, #devchat, #meetings

What’s new in Gutenberg? (26 February)

Gutenberg 7.6 brings considerable progress on the full-site editing (FSE) front, including four new FSE blocks:

  • Post Featured Image
  • Post Tags
  • Comments Count
  • Comments Form

In addition, this release includes many enhancements and fixes to existing blocks and features.

Any help testing FSE work is much appreciated. So, if possible, please enable FSE in your testing environments and share your feedback.

Gutenberg 7.6 also brings a rotating list of tips that appear in the Block Inserter to provide useful information to users:

The release also comes with developer-focused enhancements to wp-env and wp-scripts, thus improving the experience of building with WordPress.

Last but not least, this release cycle has prioritized bug fixing, and as a result this release brings numerous fixes that were also included in Betas 2 and 3 of WordPress 5.4.

Read on for the full change log.

7.6 🇱🇹

Features

  • Add a rotating list of tips to the inserter help panel 20163

Experimental

  • New blocks:
    • Post Featured Image. 19875
    • Comments Count block. 19953
    • Comments Form block. 19954
    • Post Tags block. 19580
  • Add new features to the Post Excerpt block. 19715
  • Allow changing Site Title block heading level. 20361
  • Render the post comments form properly 20279
  • Add new features to the Post Date block. 19857
  • Add multiple template loading 19141
  • Show error when resolved block template is empty 20239

Enhancements

  • Improve find-ability for social/video embeds 20224

New APIs

  • Ensure packages-update wp-scripts command works with missing dependencies 20408
  • Add new option in dependencies webpack plugin to combine assets files into one file 20330
  • Environment:
    • Add custom port numbers to .wp-env.json 20158
    • Add support for local override files. 20341
    • Add debug mode. 20348

Bug Fixes

  • Overflowing LinkControl block editor component. 20154
  • Broken gallery to image transform and inconsistent types used in the gallery block 20084
  • Missing label on heading toolbar. 20248
  • Sidebar jumpiness. 20355
  • Fix wrong imports in PluginBlockSettingsMenuItem 20356
  • Color formatter appears when color choosing is not possible 20222
  • Crash when updating a post with the latest post block 20289
  • Inconsistency on Import from JSON button look 20416
  • Inline image width pop-up ‘wanders’ down page 20232
  • Styling problem on vertically aligned blocks 20368
  • Remove unnecessary aria-label from link formatter 18742
  • Make navigation button expand to fit longer nav link text 20230
  • Flow for gallery creation and editing 20287
  • Fix background color for dark themes on the spacer block 20296
  • Show metaboxes peeking in even on tiny screens. 20262
  • Add an edit state to media frames to fix an issue when opening a new tab. 17642

Documentation

Various

  • Create block: Add support for format:js to ESNext template 20335
  • Add check for minimum system requirements on create block 20398
  • Conditionally apply Editor Skeleton html element styles 20245
  • Environment:
    • Check for legacy installs and provide the option to delete them. 20340
    • Fix testsPath on local sources 20353
    • Use user with UID=33 to run WP CLI commands 20403
    • Fix issue where docker & wp had different URLs 20228
    • No longer show error message twice 20157
    • Support wp-config.php overrides. 20352
    • Support overwriting generated file directory with an environment variable 20253

Performance Benchmark

The following benchmark compares performance for a particularly sizeable post (~ 36000 words, ~ 1000 blocks) over the last releases. Such a large post isn’t representative of the average editing experience but is adequate for spotting variations in performance.

Version Loading Time KeyPress event (typing)
Gutenberg 7.6.0 7.7s 48.59ms
Gutenberg 7.5.0 8.5s 55.45ms
WordPress 5.3 7.9s 77.23ms

#core-editor, #editor, #gutenberg

Editor chat summary: Wednesday, 26 February 2020

This post summarizes the latest weekly Editor meeting, held in the #core-editor Slack channel, on Wednesday, February 26, 2020, 14:00 UTC.

WordPress 5.4 Upcoming Release

Gutenberg 7.6.0

  • RC will be released on Monday.
  • The changelog can be checked on https://github.com/WordPress/gutenberg/releases/tag/v7.6.0-rc.1.
  • The FSE work evolved a lot, and Gutenberg 7.6 includes four new FSE blocks, besides many enhancements and fixes to the existing blocks and functionality.
  • Any help testing FSE work is much appreciated, enable FSE on your test/in development projects and share your feedback.
  • Enhancement to wp/env and wp-scripts to make the developer experience better.

Weekly Priorities

  • The first iteration of G2 (Block UI redesign) has been merged into master and will make it into Gutenberg 7.7.

Task Coordination

Note: Anyone reading this summary outside of the meeting, please drop a comment in the post summary, if you can/want to help with something.

@nosolosw

@youknowriad

  • Working on G2.
  • Starting a new project with @nrqsnchz about Block Patterns.
  • Help with G2 follow-ups.
  • Triaging old issues.

@joen

@mcsf

  • Followed up on items related to Social Icons.
  • Discussed block variations and patterns with @gzioloo.
  • Pitched in around dev notes for 5.4, and some reviews.
  • Exploring how to implement embeds as block variations.

@ellatrix

  • Continuing work on lightening the block DOM and allowing blocks to render the entire block and inner block wrappers, hopefully making it easier to style block for block and theme authors. 

@brentswisher

@gziolo

  • Paired with @azaozz to improve the build process for the editor’s JavaScript scripts in WordPress core.
  • A few bug fixes/enhancements for @wordpress/scripts and @wordpress/create-block packages.
  • Several reviews including SlotFill refactor.
  • Plan to work on the block features API proposed by @youknowriad.

@getdave

@itsjusteileen

  • Working on FSE and block templates from a user and theme creator perspective.

@andraganescu

Open Floor

Capitalization in strings used in the editor

Encouraging component maintainers to get involved with the non-editor parts of Gutenberg

  • @noisysocks some discussion around how to encourage Widget component maintainers to get involved with the experimental Block Widgets functionality. There’s a lot of expertise there that the Core Editor team could use.
  • @youknowriad suggested inviting component maintainers to the core editor channel.

Query Blocks

  • @andraganescu some discussion around reusability of query block https://github.com/WordPress/gutenberg/pull/20106
  • @revgeorge It’s working, but I’m working with @epiqueras to figure out how to best structure it’s de-duplication feature, or possibly going ahead without de-duplication at launch. It’s behind the FSE flag in the branch because it needs the post blocks to display results
  • @itsjusteileen from a plugin perspective, I’d love to see it with de-dupe
  • @revgeorge I can show you how I plan to use it with a plugin use case. The current plan for deduplication is to provide a container block that uses hooks to provide a way for blocks to get a list of displayed posts and add to that list, the container would be aware of the order the blocks are in and what they’ve displayed.
  • @gziolo what’s the difference between Query block and Latest Posts block?
  • @youknowriad Query block doesn’t have a fixed output based on attributes, it uses InnerBlocks to render each “post”. So you could combine PostTitle, post content, PostExcerpt, Post* blocks as a template for each “Post” entry in the Query block.

Semantic HTML inside the Group block

#meeting-notes, #core-editor, #editor, #gutenberg

Feature Plugin: WP Auto-updates

In 2018, @matt posted 9 projects for Core to focus on in 2019. This roadmap was updated for 2020. Plugins and Themes automatic updates is one of those 9 projects. WordPress contributors did a lot of work on the two related tickets during WP 5.4 development cycle, but decided to give it more time for testing as it’s an important feature. This project is now planned for WordPress 5.5 and the feature is going to be tested in a Feature Plugin.

For reference, see the two related Trac tickets:

A lot of interesting points were discussed in the tickets above, including the scope of the feature and the user interface/design. Many thanks to everyone who already contributed to this exciting new feature ♥️

Now, the development that happened in the related tickets are moved into WP-Auto-updates Feature Plugin which is available for testing and feedback. Contributions from the WordPress community are welcome on the plugin’s GitHub repository.

Project overview

As a quick reminder of what this project is trying to achieve, here are the main features that are being worked on:

  • Ability for website administrators to opt-in to automatic updates for plugins and themes in the related WP-Admin screens.
  • Ability to enable/disable auto-updates on a plugin-by-plugin and theme-by-theme basis.
  • Email notifications to send regular auto-update summaries to website administrators.
  • Hooks and constants to help developers disable or programmatically define auto-update settings.

Design considerations

The current design of the feature plugin reflects the last ideas that were discussed in #48850. This is still a work in progress and the implementation will probably evolve, as WordPress contributors discuss the feature on GitHub.

Latest Plugin screen mockup in #48850
WP Autoupdates screenshot
Current implementation in WP Auto-updates Feature Plugin – version 0.1.2

Here is the proposed roadmap:

  • ✅ Create feature plugin
  • ✅ Submit feature plugin to WordPress.org repository
  • ✅ Get the plugin featured as beta plugin on WordPress.org
  • 🔲 Move the repository to WordPress.org GitHub account
  • ✅ Publish the feature plugin proposal
  • 🔲 Open a dedicated Slack channel on Make WordPress (if needed)
  • ✅ Handle plugins auto-updates
  • 🔲 Handle themes auto-updates
  • ✅ Handle plugins auto-updates in a multisite context
  • 🔲 Handle themes auto-updates in a multisite context
  • ✅ Add hooks and constants for plugins
  • 🔲 Add hooks and constants for themes
  • 🔲 Add email notifications for plugins
  • 🔲 Add email notifications for themes
  • ✅ Add auto-updates information in update-core screen
  • 🔲 Validate design for plugins screen
  • 🔲 Validate design for themes screen
  • 🔲 Validate design for update-core screen
  • 🔲 Full documentation for new functions, hooks and constants
  • 🔲 Copy review
  • 🔲 Accessibility review
  • 🔲 Security review
  • 🔲 Coding standards review
  • 🔲 Inline Docs review

Next steps

The release of the WP-Auto-updates feature plugin is an early step in the process of having this functionality included in WordPress Core. Now, your help is needed to test, validate, and improve the current feature to ensure that it meets the needs of the WordPress community. Plugin and theme authors, hosting companies, WordPress developers and users are welcome to share their thoughts about this feature.

#5-5, #feature-plugins, #feature-autoupdates

Dev Chat Agenda for February 26, 2020 (5.4 Week 7)

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

Announcements

  • This week marks week 6 of the 5.4 release cycle 🙌
  • WordPress 5.4 Beta 3 was released yesterday, February 25, as scheduled.

Highlighted Blog Posts

Upcoming Releases – 5.4

Components Check-in

  • News from components
  • Components up for adoption (Filesystem API and Rewrite Rules)
  • Components that need help
  • Cross component collaboration

Open Floor


If you have anything to propose for the agenda or specific items related to those listed above, please leave a comment below.

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

#5-4, #agenda, #devchat

Miscellaneous Developer Focused Changes in WordPress 5.4

WordPress 5.4 adds a handful of small developer-focused changes. Let’s take a look!

Better information about errors in wp_login_failed

A new parameter, $error, gets passed in the wp_login_failed action, to get you more information about the error that caused login failure.

It’s the second argument of the action and holds a WP_Error object with the authentication failure details.

Find it in wp-includes/pluggable.php:

/**
 * Fires after a user login has failed.
 *
 * @since 2.5.0
 * @since 4.5.0 The value of `$username` can now be an email address.
 * @since 5.4.0 The `$error` parameter was added.
 *
 * @param string   $username Username or email address.
 * @param WP_Error $error    A WP_Error object with the authentication failure details.
 */
do_action( 'wp_login_failed', $username, $error );

See this related ticket on Trac: #49007

Multisite: add site ID to newblog_notify_siteadmin filter

A new parameter, website ID, gets passed in the newblog_notify_siteadmin filter, to help you to customize site admins notifications depending on the website ID.

Find it in wp-includes/ms-functions.php:

/**
 * Filters the message body of the new site activation email sent
 * to the network administrator.
 *
 * @since MU (3.0.0)
 * @since 5.4.0 The `$blog_id` parameter was added.
 *
 * @param string $msg Email body.
 * @param int$blog_id The new site's ID.
 */
$msg = apply_filters( 'newblog_notify_siteadmin', $msg, $blog_id );

For more, see the relevant ticket: #48554

Introducing TikTok videos embed

WordPress 5.4 introduces TikTok as a new oEmbed provider.

As of version 5.4, WordPress will recognize TikTok video URLs that follow this pattern:

'#https?://(www\.)?tiktok\.com/.*/video/.*#i'

TikTok support also comes with its own block for the editor.

Plus, TikTok embeds work in the Block and Classic Editors, in the Text Widget — and anywhere else you can use Embeds now.

For more, see:

  • Related ticket on Trac: #49083
  • Related pull request on Gutenberg GitHub repository: 19345

Removal of CollegeHumor video embed

Since the CollegeHumor service no longer exists, its oEmbed provider was removed from Core in WordPress 5.3.1.

With version 5.4, the service is now completely gone from WordPress and the corresponding Gutenberg Embed block is deprecated. For backward compatibility, existing CollegeHumor blocks will automatically be converted into a generic embed block.

For reference, see:

  • Related ticket on Trac: #48696
  • Related pull request on Gutenberg GitHub repository: 18591

Media: store the original URL of the attachment in the _source_url post meta value

When you use media_sideload_image to sideload a file from a URL, the original URL is now automatically stored as metadata.

You can also use media_sideload_image to store a local copy of a file.

This is great for two reasons. First, for copyright and fairness, storing the source URL gives you an easy way to find out where that file was originally hosted. Plus, you can query existing attachments and not sideload the same file twice.

The original URL of the attachment is stored in the _source_url post meta:

add_post_meta( $id, '_source_url', $file );

For reference, see the related Trac ticket: #48164

Accessibility: the Admin Bar is now loaded with wp_body_open when available

It’s a first principle of accessibility that the look of a page and its source order should match. And for far too long, it’s been a principle WordPress has observed inconsistently.

Consider the Admin Bar. Up to now, it’s been loaded with the wp_footer hook:

add_action( 'wp_footer', 'wp_admin_bar_render', 1000 );

In WordPress 5.4, the Admin Bar loads in the hook wp_body_open(new since WP 5.2) and fixes that source-order problem:

add_action( 'wp_body_open', 'wp_admin_bar_render', 0 );

Of course, some older themes don’t yet support the wp_body_open hook. For them, there’s a fallback in the wp_footer function:

function wp_footer() {
    /*
     * Sets up the Admin Bar if the current theme does not use `wp_body_open`.
     * @since 5.4.0
     */
    if ( ! did_action( 'wp_body_open' ) ) {
        add_action( 'wp_footer', 'wp_admin_bar_render', 1000 );
    }
}

See the relevant Trac ticket: #47053

Widgets: avoid duplicate IDs in Recent Comments

In WordPress 5.4, the Recent Comments widget will no longer generate widgets with the same HTML id.

Even if having duplicate instances of Recent Comments widgets on the same patch is considered as an edge case, theme authors are invited to avoid to style this widget using the ID applied on the <ul> HTML element, as the ID will be different for each instance of the widget.

For reference, see the related Trac ticket: #46747

Login and Registration: new parameter passed into the lostpassword_post action in retrieve_password()

In WordPress 5.4, the $user_data parameter gets passed into the lostpassword_post action in retrieve_password().

If the user exists, $user_data will return the corresponding WP_User object. Otherwise, the parameter will return false.

Either way, developers have one more piece of information to act on.

See the related Trac ticket: #38334

Themes headers now support “Requires at least” and “Requires PHP” declarations

WordPress 5.4 adds support for required WordPress and PHP versions to themes.

Theme authors are invited to declare the following header entries in their main stylesheet:

Requires PHP: declare the minimal required PHP version.

Requires at least: declare the minimal WordPress version.

Post types capabilities improvements in WordPress 5.4

In WordPress 5.4, delete_posts capability will be included in default post type capabilities regardless of map_meta_cap value.

This resolves eventual PHP notices in a few places in WordPress core where this capability is checked. Before WP 5.4, PHP notices could be triggered by using 'map_meta_cap' => false in the post type declaration.

With delete_posts added to the get_post_type_capabilities() function, no PHP notices will be triggered anymore for this capability.

For reference, see the related Trac ticket: #30991

#5-4, #dev-notes