JavaScript chat summary, April 23th, 2019

Below is a summary of 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.

Webpack plugin to extract script dependencies

Another update was shared on a Webpack plugin discussed during the previous week’s meeting, which helps provide automation for the tedious and error-prone task of manually maintaining script dependencies. The pull request was merged this past week: PR#14869. It won’t be published to npm until WordPress 5.2 is released.

There’s a follow-up issue at PR#14837 which aims to replace the existing manually maintained packages-dependencies.php file in Gutenberg. There’s an open question there about how we handle “legacy” scripts which are still referenced on the window global, as these aren’t explicit but rather implicit dependencies. We discussed several possible solutions and decided to take the following steps:

  1. We know what these implicit dependencies are and which scripts depend on them, let’s merge those into the “extracted” set? There is already a follow-up PR#15124 opened (shortly after the meeting) by @jonsurrell.
  2. We were all in agreement that referencing the window globals is itself a problem we need to address. This is incompatible for use in an npm context and should be eliminated or substituted with an equivalent package. @aduth created an issue#15125 to keep track of it.

#javascript

Site Health Check in 5.2

WordPress 5.2 will include two new pages in the admin interface to help end users to self-service their site through common configuration issues and other elements that go along with having a healthy online presence. It also provides a standardized location for developers to add debugging information.

The new pages can be found under the Tools menu, as Site Health, and presents the user with a fresh new admin interface. As we hope users will regularly ensure their site is up to standards, focus has been put on creating an interface you want to return to in the future.

Site Health Status

Screenshot of the WordPress Site Health Status page

The first page runs a series of tests on the user’s site, and will be categorized as critical, recommended, or good responses. These outcomes also affect the percentage of completion you have (where critical is weighted more heavily than recommended).

Each test result can be expanded to get an explanation of what you as a user should be paying attention to, and which problems are there if any, that need addressing.

Most of the bundled tests will also have actionable items, and provide links directly to the appropriate areas of your dashboard where you can improve upon the relevant settings.

Filtering the Tests

The tests are filterable via site_status_tests, meaning plugins or themes may add their own tests, or remove existing ones. We’ve also split these into two different types of tests: direct  and async. This was done as some tests may require more time to run, so to avoid potential timeouts within admin pages, any tests added to the async section will be run in succession via AJAX calls after the page is loaded.

Specifically of interest to server admins is the companion filter site_status_tests_php_modules, which is based off the WordPress Hosting Team list of recommended and required PHP extensions.

Removing a Test

An example of a filter use would be a hosting provider that does automated updates. They may wish to remove the test for background updates being enabled or disabled as follows:

function myhost_remove_update_check( $tests ) {
	unset( $tests['background_updates'] );
	return $tests;
}
add_filter( 'site_status_tests', 'myhost_remove_update_check' );

Adding a Test

This is an example of how a caching plugin might check to ensure that it’s cache setting is enabled.

<?php
function myplugin_add_caching_test( $tests ) {
	$tests['direct'] = array(
		'caching_plugin' => array(
			'label' => __( 'My Caching Test' ),
			'test'  => 'myplugin_caching_test',
		),
	);
	return $tests;
}
add_filter( 'site_status_tests', 'myplugin_add_caching_test' );

function myplugin_caching_test() {
	$result = array(
		'label'       => __( 'Caching is enabled' ),
		'status'      => 'good',
		'badge'       => array(
			'label' => __( 'Performance' ),
			'color' => 'orange',
		),
		'description' => sprintf(
			'<p>%s</p>',
			__( 'Caching can help load your site more quickly for visitors.' )
		),
		'actions'     => '',
		'test'        => 'caching_plugin',
	);

	if ( ! myplugin_caching_is_enabled() ) {
		$result['status'] = 'recommended';
		$result['label'] = __( 'Caching is not enabled' );
		$result['description'] = sprintf(
			'<p>%s</p>',
			__( 'Caching is not currently enabled on your site. Caching can help load your site more quickly for visitors.' )
		);
		$result['actions'] .= sprintf(
			'<p><a href="%s">%s</a></p>',
			esc_url( admin_url( 'admin.php?page=cachingplugin&action=enable-caching' ) ),
			__( 'Enable Caching' )
		);
	}

	return $result;
}

myplugin_add_caching_test() is hooked to the site_status_tests filter. It adds a new test called caching_plugin to the direct tests list. The value of test in this array is the function that will be called when the tests run on the Site Health Status page.

Note: If you add a test to the async test list, then you will also need to register the test function as an AJAX action using the wp_ajax_{$action} hook.

The test function should return an array with data about the result of the test. This array includes:

  • label: What the header of the section should say.
  • status: Section the result should be displayed in. Possible values are good, recommended, or critical.
  • badge: Array containing:
    • label: What the badge should say.
    • color: Applies a CSS class with this value to the badge. Core styles support blue, green, red, orange, purple and gray.
  • description: Additional details about the results of the test.
  • actions: A link or button to allow the end user to take action on the result.
  • test: The name of the test.

In the above example, the test function, myplugin_caching_test() sets an initial baseline value for the result, and then overrides portions as needed if the call to its internal function myplugin_caching_is_enabled() returns false.

Site Health Info

Screenshot of the WordPress Site Health Information page

The Information tab is meant for debug purposes. It provides a plethora of information about the website and server setup for sharing when looking for support in various locations, alongside a button to quickly copy any non-private information so you can easily paste this to others.

The page is split up into sections. Plugins and themes may introduce their own entries to this page using the debug_information filter, either by adding entries to existing sections, or by creating their own sections.

As mentioned, the copied information only includes non-private information, this can of course be subjective, and is therefore also included in the filter. Marking either a full section, or just individual entries as private can be done by setting the corresponding $private value to true.

For example, the database prefix is shown under the Database section, and is marked as private, so when I go to copy all the information, it’s not there:

Example of the database section of the Site Health Information page

The content that gets added to the clipboard for the entire Database section is shown below:

### Database ###

Extension: mysqli
Server version: 5.5.5-10.1.38-MariaDB-1~jessie
Client version: mysqlnd 5.0.12-dev - 20150407 - $Id: 7cc7cc96e675f6d72e5cf0f267f48e167c2abb23 $

A security plugin may for example think that any database information is always seen as private, and would filter this in the following way:

function secplugin_remove_database_info( $debug_info ) {
	$debug_info['wp-database']['private'] = true;
	return $debug_info;
}
add_filter( 'debug_information', 'secplugin_remove_database_info' );

Adding a new section may also be of interest. The example below adds your own plugin and its license key, but marks it as private, to the list:

function myplugin_add_debug_info( $debug_info ) {
	$debug_info['my-plugin-slug'] = array(
		'label'    => __( 'My Plugin', 'my-plugin-slug' ),
		'fields'   => array(
			'license' => array(
				'label'    => __( 'License', 'my-plugin-slug' ),
				'value'   => get_option( 'my-plugin-license', __( 'No license found', 'my-plugin-slug' ) ),
				'private' => true,
			),
		),
	);

	return $debug_info;
}
add_filter( 'debug_information', 'myplugin_add_debug_info' );

Each new section that’s added should use your plugin or theme slug to avoid name collisions. All core entries are prefixed with wp-.

All debug information is added in an unescaped manner, the Information page will run all data through wp_kses, and only allows a, strong, em and span tags (used for emphasis or linking to documentation).

#5-2, #dev-notes

Dev Chat Summary: April 24

Announcements

Josepha (@chanthaboune) is working on bringing us a 5.0 retrospective wrap up, a project digest, and a team lead interest form. She is planning to publish the retrospective wrap up this week and potentially the project digest soon after in the following week. Thank you, Josepha!

5.2 updates

#46898 WSOD Protection could use some copy review

RC1 is planned for today, with the *target release date in ~2 weeks*

Josepha brought attention a few items needing help:

There were 11 tickets open in the 5.2 milestone but that is now down to 3 as of writing this summary. @pento worked through a bunch the evening prior to devchat and @sergeybiryukov has been lending a hand today. Many of these will be moved out of the milestone, but if there are any still at this link, feel free to discuss or do the next step.

The about page outline will be ready for RC1 and will be final in the final release. Most of text should be in by RC-1 but it is not “frozen” in this time period.

Dev Notes

There are a few dev notes that are still in draft. @jeffpaul is working through the field guide and adding placeholders for those. It would be much appreciated if you’d finalize your notes so we can include them! Ideally these would release along side RC1.

Please use the following link as a list of what is pending for dev-notes: link here. If the dev note has been made, please remove the needs-dev-note keyword. 🙂

Open Floor

Influx in Forum issues/Trac Tickets

There was discussion around the continued cadence and nature of Minor/Major releases. @joyously said that she has noticed an influx in forum posts focused around bugs. Joy reminded us that directing folks to create tickets in the forums will help greatly in identifying common bugs. This also serves as a reminder that there are teams for triage in both Trac and the Gutenberg Github repo that would greatly appreciate the help. The Gutenberg triage has recently moved to a weekly cadence and the times are as follows:

Gutenberg #core-editor triage times are – Monday at 13:00 UTC

Gutenberg #design triage times are every Tuesday at 16:00 UTC

@jorbin punted #46293 as there was no decision made and there is a need to freeze strings. Many thumbs up emojis agreed. 👍

#5-2, #devchat, #summary

Miscellaneous Developer Updates in 5.2

New wp_body_open Theme Hook

5.2 will introduce a new wp_body_open() function that is used to trigger a wp_body_open action. This action is intended to allow developers to inject code immediately following the opening <body> tag.

Themes are encouraged to begin using this hook as soon as 5.2 is released. The function should be placed just inside the opening <body> tag of the template file. For example:

<body <?php body_class(); ?>>
<?php wp_body_open(); ?>

Usage of this hook should be reserved for output of unseen elements like <script> tags or additional metadata. It should not be used to add arbitrary HTML content to a page that could break layouts or lead to unexpected situations.

Backward Compatibility

In order to support previous versions of WordPress, it is recommended you use a shim in your theme to prevent fatal errors from the undefined function.

<?php
if ( ! function_exists( 'wp_body_open' ) ) {
    function wp_body_open() {
        do_action( 'wp_body_open' );
    }
}

Note that if your theme is going to be submitted to the theme repository, then you won’t be able to use the wp_ prefix, as it will get flagged by the Theme Check. An alternative is to call do_action directly where the wp_body_open() function is placed in the first example, like this:

<body <?php body_class(); ?>>
<?php 
if ( function_exists( 'wp_body_open' ) ) {
    wp_body_open();
} else {
    do_action( 'wp_body_open' );
}

Plugins can detect the use of this function in a theme by calling did_action( 'wp_body_open' ) and falling back to alternative methods if the action has not fired.

See #12563 and #46679 for more information.

Login Header Adjustments

The <h1> on wp-login.php previously used the title attribute inconsistently between multisite and single site. In multisite, the value of this attribute was the title of the network, but on a single site, it merely duplicated the link text. As part of #24766, many of the title attributes throughout core have been removed, as they are often redundant or useless.

In WordPress 5.2, this title attribute has been removed and its associated filter, login_headertitle, has been deprecated. If the deprecated filter is used, it now applies to the link text. A new login_headertext filter has been added in its place.

In addition to the <h1> changes, the link on the WordPress logo now always points to WordPress.org by default. In prior versions, it would point to the primary site of the network on multisite. This URL can still be filtered using login_headerurl.

See: #42537

Editor Image Caption Styles

In the block editor, the font-size and color attributes were removed from the figcaption element unless the active theme has opted into default block styles.

Additionally, a margin: 0; attribute applied to .block-editor-rich-text__editable was removed from the RichText component, so as to allow theme styles to control those margins without high specificity. If your plugin relied on this margin, you’ll need to add this back to the necessary elements.

See: wordpress/gutenberg/pull/14366

Walker_Category HTML Attributes

A new category_list_link_attributes filter has been added to Walker_Category to allow customization of the HTML attributes applied to a category list item’s anchor element.

This complements the page_menu_link_attributes filter in Walker_Page and the nav_menu_link_attributes filter in Walker_Nav_Menu.

See #40666

New Additional Content Filter on User Delete Action

When users are deleted from a site, WordPress checks to confirm that they do not have posts or links assigned to them. However, there are cases where a plugin may have content associated with them outside of a post_author or link_owner relationship.

WordPress 5.2 introduces a new users_have_additional_content filter, which allows plugins to run additional checks for custom content relationships.

Note: This filter specifically doesn’t override the system users_have_content checks to avoid any undesired suppression of the reassign functionality. Instead it enables the ability to flag that a user has additional content.

Developers should note that this filter doesn’t conduct the reassignment operations on the data, this will be done by the delete_user or deleted_user actions which provide the ID of the user as well as the ID of the user for reassignment if selected.

Using the Filter

Below is a simple example of how a plugin could use the filter along with the delete_user action to allow the re-assignment of non-standard content.

First the filter returns true to signify that users have additional content. This triggers the content reassignment UI to appear in the admin for all users being deleted.

It then uses the delete_user action hook to reassign additional content at the same time as any standard core content.

function myplugin_users_have_additional_content( $has_content, $user_ids ) {
	if ( ! $has_content ) {
		// Check if any of the the users being deleted have additional content
		if ( myplugin_check_users_have_content( $user_ids ) ) {
			return true;
		}
	}
	return $has_content;
}
add_filter( ‘users_have_additional_content’, ‘myplugin_users_have_additional_content’, 10, 2 );

function myplugin_reassign_user_content( $deleted_user, $reassigned_user ) {
	if ( $reassigned_user ) {
		// Re-assign the content from the deleted user
		myplugin_reassign_coauthor( $deleted_user, $reassigned_user );
	}
}
add_action( ‘delete_user’, ‘myplugin_reassign_user_content’, 10, 2 );

See: #36860

Other Updates of Note:

  • As part of the 2019 focus of improving automatic updates, the sodium_compat library will now be included in WordPress. Sodium Compat is a polyfill for the Sodium cryptography library for PHP versions <7.2. Including this will facilitate security enhancements, with the initial focus of enabling more secure signing and verification of update packages. See: #45806
  • Twemoji is now updated to version 12.0.1. See: #46805
  • Fixed a bug where an Allow header was not being returned for OPTIONS requests to the REST API. See: #45753
  • A $domain parameter has been added to translate_user_role(). This will allow translations of custom user roles added in plugins. See: #38736

#5-2, #dev-notes, #editor, #themes

Notable Accessibility Changes in 5.2

In addition to the semantic improvements to tabs in the admin area, there are a few additional accessibility changes developers should make note of in WordPress 5.2.

Post Formats in List Tables

When post formats were used prior to WordPress 5.2, icons representing the specific format were displayed beside the post title in the Posts list table. These icons served as links that filtered the list by the associated post format.

These icons have now been removed in favor of a dedicated dropdown select filter above the list table.

See: #35497, #46591

Admin Bar Submenu Link Markup

In the WordPress admin bar, menu items with nested items used arrow icons generated via CSS with a .ab-item:before pseudo element. Starting with WordPress 5.2 these arrow icons use a wrapper <span> element:

<span class="wp-admin-bar-arrow" aria-hidden="true"></span>

This change should only affect plugins that modify the admin bar using custom icons. Plugin authors are encouraged to use the new markup and adjust their plugin CSS accordingly.

This change is part of a broader effort—tracked in #40428—to progressively introduce best practices to make screen readers ignore CSS generated content when it’s not intended to be available for speech output.

See: #37513

Archive Widget Dropdown Improvements

To add consistency with the Categories Widget, and to improve contextual awareness for those using screen readers and other assistive technologies, WordPress 5.2 will now pre-select the currently viewed archive in the Archive Dropdown Widget.

This is handled through the addition of a new $selected boolean parameter in the get_archives_link() function. By default, $selected is set to true if the current page is the selected archive page. The new parameter is also available in the associated get_archives_link filter.

In addition, four new date-based parameters have been added to wp_get_archives(). By default, $year, $monthnum, $day, and $w are set to the their current date values, and are used to determine the value of $selected to pass to get_archives_link(), as noted above.

Developers utilizing wp_get_archives() may pass in different date values through these parameters to use as the comparison for the currently viewed archive page.

See: #40662

Other Changes of Note

  • A new media view, wp.media.view.Heading, was added to facilitate adding accessibility friendly headings to the media library/modal. This enables those using screen readers to quickly jump between sections of the interface. See #36925
  • Similarly, headings were added to the data tables on the Export Personal Data and Erase Personal Data pages. See #46041
  • Some minor adjustments have been made to the Alt text and URL fields in the media modals. The Alt text field is now the first field displayed, and it has an explanation below it to help educate on proper usage. The label for the “URL” field now says “Copy link” instead of “URL”. See #41612

#5-2, #accessibility, #dev-notes

Editor chat summary: April 24th


This post summarizes the latest weekly Editor meeting, held in the #core-editor Slack channel, on Wednesday, April 24, 2019, 13:00 UTC.

Tasks Coordination

  • @nerrad will resume converting effects to controls.
  • @nosolosw will start drag and drop implementation for gallery images.
  • @joen is keeping an eye on the code refactoring he did to make sure no issues arise.
  • @kjellr is working on nested block borders and a way to help make group block easier for theme developers.
  • @gziolo merged several PRs and opened some new ones to align core blocks to the RFC for Block Registration API. Need to figure out how to handle assets now. Also PRs/Issues otriage.
  • @notnownikki is working on the toolbar that affects multiple selected blocks.
  • @mapk posted about the UX flow for widgets-to-blocks.

Open Floor

Some discussion around adding resizing capability to embed block for further details follow the feature issue

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.

The meeting archive is here.

The agenda for the next meeting is here, please add anything you want to discuss.

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

Dev Chat Agenda: April 24

Below is the agenda for the weekly devchat meeting on Wednesday, April 24, 2019, 2100 UTC Wednesday, April 24, 2019, 2000 UTC.

Announcements

  • 5.2 updates
    • Coordination of tasks in our final two weeks
  • Calls from component maintainers
  • 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 in the Making WordPress Slack.

#5-2, #agenda, #devchat

Developer Focused Privacy Updates in 5.2

WordPress 5.2 brings several improvements for developers working with Privacy Policy pages and data exports.

New Privacy Policy Page Helpers

Four new features have been added to make customizing and designing the Privacy Policy page easier:

  • A new function, is_privacy_policy(), can be used in conditionals to identify whether the current $wp_query is for the Privacy Policy page.
  • A new theme template file, privacypolicy.php, is used for rendering the page assigned as the Privacy Policy.
  • .privacy-policy has been added as a body class and is inserted when the currently rendered page is the Privacy Policy page.
  • .menu-item-privacy-policy has been added as a menu item class to specify the menu link that points to the Privacy Policy page.

Backwards Compatibility

The only backwards compatibility concern with using these new helpers is with the is_privacy_policy() function, which would trigger a Call to undefined function fatal error.

Themes and plugins that would like to support the is_privacy_policy() function in older versions of WordPress can use the following shim:

<?php
if ( ! function_exists( 'is_privacy_policy' ) ) {
    function is_privacy_policy() {
        return get_option( 'wp_page_for_privacy_policy' ) && is_page( get_option( 'wp_page_for_privacy_policy' ) );
    }
}

For more information, see #44005.

Loosened Tag Restrictions in User Data Exports

User Data exports no longer use a hardcoded list of allowed tags, limited to just <a> and <br>. They will now use the default list of allowed tags in wp_kses().

Furthermore, the code facilitating the export now passes a personal_data_export context to wp_kses(), so that the allowed tags and attributes can be filtered using the wp_kses_allowed_html filter and checking for the personal_data_export context.

Here’s a filter example that adds support for the <sub> and <sup> tags to the personal data export:

function prefix_allowed_html_filter( $allowedtags, $context ) {
	// Only target personal data export.
	if ( 'personal_data_export' !== $context ) {
		return $allowedtags;
	}

	// Add support for the sub tag.
	if ( ! isset( $allowedtags['sub'] ) ) {
		$allowedtags['sub'] = array();
	}

	// Add support for the sup tag.
	if ( ! isset( $allowedtags['sup'] ) ) {
		$allowedtags['sup'] = array();
	}

	return $allowedtags;
}
add_filter( 'wp_kses_allowed_html', 'prefix_allowed_html_filter', 2, 10);

For more information, check out the documentation for the wp_kses_allowed_html filter.

See: #44044

#5-2, #core-privacy, #dev-notes, #privacy, #themes

Editor Chat Agenda: April 24th

This is the agenda for the weekly editor chat meeting on Wednesday, 24th April 2019, 13:00 UTC

  • Tasks Coordination
  • Open Floor

This meeting is held in the #core-editor channel in the Making WordPress Slack.

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

#agenda#editor-chat

X-post: The Get Involved table at WCEU 2019

X-comment from +make.wordpress.org/community: Comment on The Get Involved table at WCEU 2019