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

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.

#5-4, #dev-notes

Release Model Working Group Chat Summary: February 19th, 2020

This is the Summary of the Release Model Working Group Chat in #core on Slack at 20:00 UTC!

Folks are welcome to check out the agenda and Slack archive for this week’s meeting. Here is a recap of the last meeting, as well.

Thank you to @mikeschroder for doing the peer review on this summary!

This week a kan ban project board was introduced with new GitHub issues created!

@noisysocks broke down some of the ‘development’ phase of the pre-release cycle into individual issues for each critical step. 

A few of the issues have been assigned to contributors and more volunteers are welcome! Workflow is being broken down amongst team members as follows:

@noisysocks mentioned that some conversations have already lead to ideas for recommendations!

Next Meeting

Meetings for the Working Group will take place on the first and third Wednesday of the month at Wednesday March 4, 2020 at 08:00 UTC and Wednesday March 4, 2020 at 20:00 UTC. Hope to see you there!

#meeting-notes, #release-process

JavaScript Chat Summary: February 25, 2020

Below is a summary of the discussion from this week’s JavaScript chat (agendaSlack transcript).

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

Unit testing revisited

(Slack conversation)

The current tooling used for component testing in Gutenberg was observed to not support support React portals. An implementation of a new testing utility module was originally proposed, then later resubmitted as an incremental approach to adopt React Testing Library.

Discussion:

  • Is this about limitations of the tooling for fundamental React features, or about our approach to testing? It appears to be a little of both.
  • The conversation evolved into a discussion of how we want to test components, essentially distilled to a distinction between white-box and black-box testing.
  • There was some unclarity around what impact React Testing Library would have on our existing tools. @hazdiego joined the conversation, pointed to an earlier GitHub comment contrasting the solutions, and clarified that while it has feature parity to support replacing existing tools, it also comes opinionated with integration-style testing.

Action items:

Open Floor

WordPress 5.4 Deadlines

(Slack conversation)

@adamsilverstein made note that the WordPress 5.4 release is quickly approaching and that any work not addressed soon would need to be punted to a future release.

@aduth mentioned that a polyfill fix for URL will be needed, and that he would appreciate attention on the corresponding patch at #49360.

Webpack Build

(Slack conversation)

@gziolo mentioned that changes to the Webpack build were introduced with #48154, where one asset file is created containing all JavaScript entry points. This generated file is used to iterate and register all core scripts output from the Webpack build.

@gziolo mentioned a desire to improve upon this with better handling between development and production environments. He gave an example of the wp-warning package, which should be considered unnecessary for production, since it is a noop in that environment. Due to time constraints, this is planned to be discussed further in next week’s meeting.

#core-js, #javascript

CSS Chat Agenda: 27th February…

CSS Chat Agenda: 27th February 2020

This is the agenda for the upcoming CSS meeting scheduled for Thursday, February 27, 2020, 4:00 PM EST.

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

Agenda:

  • Idea for a CSS audit
  • Open Floor

The agenda is light this week, so if there’s anything else you would like to discuss, feel free to add additional topics in the comments!

#agenda, #core-css

WordPress 5.4 introduces new hooks to add custom fields to menu items

WordPress 5.4 introduces two new actions you can use to add custom fields to menu items, in both the Menu screen and the Customizer’s menu editor.

The following hooks are now available:

Menus admin screen

The new wp_nav_menu_item_custom_fields action fires just before the move buttons of a nav menu item in the menu editor.

You can assign five parameters:

  • $item_id: the menu item ID (integer)
  • $item: the menu item data object (object)
  • $depth: the depth of the menu item (integer)
  • $args: an object of menu item arguments (object)
  • $id: the Navigation Menu ID (integer)

Here’s a simple example:

function wporg_my_custom_field() {
	esc_html_e( 'Howdy! WordPress 5.4 is coming!', 'wporg' );
}
add_action( 'wp_nav_menu_item_custom_fields', 'wporg_my_custom_field' );

And here’s the result (highlighted in green dashed border):

The Customizer menu editor

The new wp_nav_menu_item_custom_fields_customize_template action fires at the end of the form-fields template for navigation menu items in the customizer.

The hook lets you render extra fields there and manage them with JavaScript.

This brings parity with the wp_nav_menu_item_custom_fields action.

Compatibility with existing custom walkers

These new action hooks can replace the custom walkers you’ve been using for your nav-menu fields. You’ll want to check your existing code to see where that replacement makes sense.

For more, see the related Trac ticket #47056.

For more help managing duplication in custom fields, see Trac ticket #49500. In plugins, you can avoid the issue entirely with a check for the WordPress version.

#5-4, #dev-notes, #menu-customizer, #menus

Editor Chat Agenda: 26th February, 2020

Note taker: @ajitbohra

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

  • WordPress 5.4 Upcoming Release
  • Gutenberg version 7.6.0
  • 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

Lazy-Loading Update

Since lazy-loading images via the native loading attribute was proposed for addition to WordPress core, there have been quite a few updates. With the WordPress 5.4 release cycle entering beta almost two weeks ago, there was too little time for testing the feature plugin and creating a proper core patch. The feature is now aimed at being released as part of WordPress 5.5, to be merged early in the release cycle to get further testing while fully integrated with the platform. This post is a follow-up to the original announcement, providing information about the latest updates.

Standardization of the loading attribute

The WHATWG spec pull-request for adding the loading attribute to img elements with possible values “eager” and “lazy” was recently merged, so it is now part of the HTML Living Standard (see general paragraph about lazy loading attributes and more specific information about the img loading attribute). This was a requirement for WordPress to ship with support for the feature. While it was unclear whether this was going to happen in time for the WordPress 5.4 release (which it now has), the 5.5 timeline certainly works for it, as now the feature can be merged way ahead of the initial beta.

Browser support

At the time of this publication, Chrome (76+), Edge (79+) and Opera (64+) already support the loading attribute. Firefox support was merged recently, and is intended to land in version 75. WebKit support is actively being worked on, so seeing the feature land in Safari is also on the horizon. We will monitor how browser vendors are adopting the standard, but with recent developments it looks promising. All major browsers will support the loading attribute by the time WordPress 5.5 is released (currently 2020/08/11). Please refer to caniuse.com for current updates.

State of the feature plugin

The feature plugin for lazy-loading images in WordPress core (GitHub repository) is in a good state to be used already. The exact implementation is undergoing some changes, mainly focused on optimizing the mechanism to add the loading attribute to images in post content for performance by combining it with the existing regular expression in core that adds srcset and sizes attributes. These changes will likely affect the new APIs outlined in the original post, and a dev note about the definite state will be published closer to the WordPress 5.5 release.

The plugin is ready to be widely tested. It has already undergone some testing, but we are looking for more testers! We will also like to receive any type of feedback on the implementation.

#feature-lazyloading

XML Sitemaps Meeting: February 25th, 2020

Last week we held the first of many weekly meetings for the XML Sitemaps feature project on Slack.

Meeting Recap: February 18th

We had quite a few people attending, not all of whom were familiar with the project. Thus, we started off with a small recap of the project’s scope and goals. After that we discussed various different topics:

  • How to modify the sitemaps to include/exclude certain URLS
    A pull request has been opened to add a FAQ section to the readme that aims to answer these kind of questions.
    Also, a new way to filter WP_Query instances used for sitemaps has been proposed.
  • Why are there no changefreq and priority fields?
    Those are optional fields in the sitemaps protocol and not typically consumed by search engines. The feature plugin follows other solutions like Yoast SEO who also don’t include those fields.
    Developers can still add those fields if they really want too.
  • Will there be UI controls to include/exclude content from sitemaps?
    Adding UI controls is currently a non-goal for the project.
  • Calculating the last modified date for URLs
    This is rather difficult and computationally expensive in WordPress. Given that sitemaps are first and foremost a discovery mechanism for content, having this data is not necessarily required. We will explore omitting this functionality (GitHub issue).
  • The default limit of 2000 URLs per sitemap is considered high and might need to be re-evaluated.
  • Potential compatibility issues with other XML Sitemaps plugins have been discussed.
    If a site ends up having two sitemaps by accident that wouldn’t be bad. However, the current /sitemap.xml URL might clash with other plugins. A GitHub issue has been opened to suggesting using /wp-sitemap.xml as the base. This would avoid conflicts in this regard.

Agenda: February 25th

The next meeting will be held on Tuesday, February 25 at 16.00 CET

For tomorrow’s meeting, the agenda is rather brief:

  • Updates since last week (merged changes, new issues)
  • Next steps for proposed lastmod changes
  • Next steps for URL naming change
  • Planning release of version 0.2.0

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, #seo, #xml-sitemaps