Miscellaneous Developer Focused Changes in WordPress 5.5


Edit 7/29/2020: a call out specific to Twenty Ten was added for the comment_type change.

Edit 8/10/2020: add wp_slash() and adminadmin (and super admin) viewport changes in “Additional developer changes” section.


WordPress 5.5 comes with a number of small developer-focused changes. Here’s a summary of what you can expect.

Upgrade/Install: updating a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party or theme by uploading a ZIP file

Starting in WordPress 5.5, it will be possible to update a plugin or theme by uploading a ZIP file. After uploading the ZIP file, a comparison table will be displayed to the user, detailing the differences between the uploaded ZIP and the version of the plugin currently installed.

The majority of this process is handled by the new do_overwrite() methods within the Theme_Installer_Skin and Plugin_Installer_Skin classes. However, there are a few hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. that can be used to adjust the output of this feature:

  • The install_plugin_overwrite_comparison and install_theme_overwrite_comparison filters can be used to modify the output of the comparison tables.
  • The install_plugin_overwrite_actions and install_theme_overwrite_actions filters can be used to modify the actions displayed after an update has failed when overwriting is allowed.
  • The upgrader_overwrote_package action is fired when a plugin or theme has been successfully been upgraded/replaced with a new version uploaded by ZIP.

For more information, refer to #9757 on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress..

Themes: functions calling locate_template()now have a return value

The template loading functions have historically not returned any values. When called, they execute silently, even if the desired template file is missing. This makes it difficult to debug situations where there is a typo in the template name details passed to the function.

Starting in 5.5, the following functions now return false if the template file is not found, and void if the template is found and loaded:

  • get_header()
  • get_footer()
  • get_sidebar()
  • get_template_part()

This could also be used for themes to check for missing template files and execute code when one is missing. For example:

<?php
if ( false === get_header( 'post' ) ) {
    // Do something when the `header-post.php` file is missing or cannot be loaded.
}

Note: Previously, returning a value when the template was loaded successfully was explored. However, this approach is not feasible. It was discovered that many themes in the wild are printing the return value of get_template_part(), leading to unexpected (and potentially compromising) content being sent to the browser.

For more information, check out the related ticketticket Created for both bug reports and feature development on the bug tracker. on Trac: #40969.

TaxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies.: default categories for custom post types

For the post post type, a default categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. term (“Uncategorized” by default) is applied to every published post. Starting in 5.5, this default term can be applied to posts of any custom post typeCustom Post Type WordPress can hold and display many different types of content. A single item of such a content is generally called a post, although post is also a specific post type. Custom Post Types gives your site the ability to have templated posts, to simplify the concept. with the category taxonomy registered to it. This can be accomplished using the new default_category_post_types filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output..

For more information, refer to #43516 on Trac.

Taxonomy: support for default terms in custom taxonomies

A new default_term argument has also been added to register_taxonomy(). Using this argument, a default term name (and optionally slug and description) can be defined. If the defined term does not exist, it will be created automatically.

Additionally, a default_term_$taxonomy option will be added to the database for easy access, and parity with default_category.

For more information, see #43517 on Trac.

Comments: default comment_type value now enforced

Since [9541], an empty string has been used as the default value of a comment’s comment_type field (though it was possible for this to be empty sooner). While examining the possibility of introducing custom comment types in #35214, this was identified as something that would potentially be problematic.

Starting in WordPress 5.5, comment will be enforced as the default comment_type for all comments going forward. This change is one of the first step to open the door to potentially supporting custom comment types.

After upgrading to 5.5, an upgrade routine will be scheduled via cron and run to update all preexisting comments with an empty comment_type to comment. This process will batch comments 100 at a time. The batch size can be adjusted using the wp_update_comment_type_batch_size filter.

If a conditional checks that $comment->comment_type is an empty string in your plugin or theme, it is possible that this change could cause comments to stop displaying on your site. Twenty Ten was the only default theme affected by this. Though it has been fixed and the theme will be updated along with 5.5, any theme built off of Twenty Ten should be updated.

For more information, see the related tickets on Trac (#49236, #35214).

Comments: Changes to return values

With the aim of consistency and WordPress 5.5 will bring a few changes to the values wp_update_comment() returns.

First, a new parameter, $wp_error, has been added to control whether a WP_Error is returned when an error is encountered. This is optional, and will default to false (do not return a WP_Error object).

Second, the return values for an invalidinvalid A resolution on the bug tracker (and generally common in software development, sometimes also notabug) that indicates the ticket is not a bug, is a support request, or is generally invalid. comment or post ID has been changed from 0 to false. This addresses an issue where 0 could be returned for three different scenarios.

Any code checking explicitly for 0 as a returned value of wp_update_comment() will need to be updated to instead explicitly check for false.

For more information, see the related ticket on Trac (#39732).

Additional developer changes

  • Build/Test Tools: The documentation for the Docker environment included with CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. for local development and the environment overall has been improved. Contributors are encouraged to give it a try and report any breakage they experience. (see #50058).
  • Docs: All instances of @staticvar within inline PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 docs have been removed. This tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) is no longer supported in phpDocumentor (see #50426).
  • Formatting: loading has been added as an allowed attribute for the <img> tag in the KSES functions (see #50731).
  • Formatting: wp_filter_object_list() now properly returns an array when passed an object with magic methods (see #50095).
  • General: The logic in add_magic_quotes() has been adjusted to prevent inappropriately recasting non-string data types to strings. This was noticeable in the REQUEST_TIME and REQUEST_TIME_FLOAT values in the $_SERVER super global (see #48605).
  • Login and Registration: The new lostpassword_errors filter in retrieve_password() allows developers to add or modify the errors generated during a password reset request (see #49521).
  • Media: the media grid frame is now exposed via the wp-media-grid-ready trigger for easier customization (see #50185).
  • Query: A new set_404 action has been introduced, firing after a 404 is triggered (see #48061).
  • Query: The found_posts property of WP_Query will now always be an integer (#42469).
  • Site Health: The error messages displayed to a user when the site does not meet the PHP or WordPress requirements of the plugin being activated have been improved to list those requirements and include a link to support documentation for updating PHP (see #48245).
  • TinyMCE: TinyMCE has been updated to version 4.9.10 (see #50431).
  • Upgrade/Install: an additional hook_extra parameter has been added to the upgrader_pre_download filter. This will provide additional context to code hooked onto this filter, such as which plugin or theme update will be downloaded (see #49686).
  • Upload: a new pre_wp_unique_filename_file_list filter has been added to wp_unique_filename(). This can be used to short-circuit the scandir() call to provide performance improvements for large directories (see #50587).
  • Administration: Remove multiple viewport metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. tags from mobile pages (see #47369).
  • Administration: Introduce the wp_admin_viewport_meta() function, paired to the admin_viewport_meta filter to control attributes of the meta tag (see #47369).
  • Formatting: Prevent wp_slash from returning non-strings as strings (see #42195).

Props @desrosj and @sergeybiryukov for reviewing/helping providing some sections.

#5-5, #dev-notes

WordPress 5.6: What’s on your wishlist?

With the 5.5 releaseRelease A release is the distribution of the final version of an application. A software release may be either public or private and generally constitutes the initial or new generation of a new or upgraded application. A release is preceded by the distribution of alpha and then beta versions of the software. scheduled for August 11th, let’s start planning for 5.6! We always aim to fix bugs, add new tools, and makemake A collection of P2 blogs at make.wordpress.org, which are the home to a number of contributor groups, including core development (make/core, formerly "wpdevel"), the UI working group (make/ui), translators (make/polyglots), the theme reviewers (make/themes), resources for plugin authors (make/plugins), and the accessibility working group (make/accessibility). WordPress better than ever for users. Components of Full Site Editing are still at the top of the WordPress goals list; 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.6?
  • What are the current UXUX User experience 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.6 and need some review/feedback/approval/etc?

Note: Adding your ticketticket Created for both bug reports and feature development on the bug tracker. here won’t necessarily guarantee inclusion. But no one can fix things they can’t see, so bravely share your thoughts!

Deadline August 20, 2020

#5.6

New wp_get_environment_type() function in WordPress 5.5

Edit: 7/28/2020: Previously, this feature included filters to modify the environment type and available environment types. These were removed in [48662] as the function is called too early for any plugins to properly hook into these filters. This post was updated to remove mention of those filters appropriately.

WordPress 5.5 introduces a new wp_get_environment_type() function that retrieves a site’s current environment type. This allows pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and theme authors to more easily differentiate how they handle specific functionality between production and development sites in a standardized way.

By default, this function will return production. Other values supported by default are development and staging.

Below is an example of how this new function can be used to determine a site’s environment type.

switch ( wp_get_environment_type() ) {
    case 'development':
        do_nothing();
        break;
    
    case 'staging':
        do_staging_thing();
        break;
    
    default:
        do_production_thing();
        break;
}

Of course care should be taken with this kind of functionality to test all the possible routes. Keep in mind that site owners and hosts are are always free to add more types as necessary.

Setting the environment type

There are two ways to set the environment type for a site. They are processed in the following order with each sequential option overriding any previous values: the WP_ENVIRONMENT_TYPE PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 environment variable, and the WP_ENVIRONMENT_TYPE constant.

For both of them, if the environment value is not in the list of allowed environments, the default production value will be returned.

The simplest way is probably through defining the constant:

define( 'WP_ENVIRONMENT_TYPE', 'staging' );

Note: When development is returned by wp_get_environment_type(), WP_DEBUG will be set to true if it is not defined in the site’s wp-config.php file.

Specifying approved environment types

Similar to setting the environment type, there are two ways to specify approved environment types. They are processed in the same similar manner as setting the type above with each sequential option overriding any previous values: the WP_ENVIRONMENT_TYPES PHP environment variable, and the WP_ENVIRONMENT_TYPES constant.

Assume a site wishes to support a test environment type. Below is an example of defining the constant:

define(
    'WP_ENVIRONMENT_TYPES',
    array(
        'production',
        'staging',
        'development',
        'test',
    )
);

Request to all hosts and development environments

All hosts that support setting up staging environments are requested to set this feature to staging on those staging environments. Similarly we ask all developers with development environments to set this value to development appropriately.

Plugin and theme developers should also add support for this feature and adjust functionality appropriately based on the specified environment.


For reference, see the related ticketticket Created for both bug reports and feature development on the bug tracker. on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.: #33161

Props @desrosj, @audrasjb, and @sergeybiryukov for reviewing.

#5-5, #dev-notes

Controlling Plugin and Theme auto-updates UI in WordPress 5.5

Site security is an integral part of modern websites. Keeping sites up to date by running the latest versions of WordPress, PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20, and any installed plugins or themes is highly recommended as an easy way to keep a site safe from any known security vulnerabilities.

By default, WordPress itself is configured to automatically update when new minor versions become available. While the code to auto-update plugins and themes has been in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. for just as long, it’s seldom used by site owners because it requires the use of a filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. hook.

This past February, a feature plugin was created in response to the 9 Projects for 2019/2020 to explore introducing a user interface that allows site administrators to easily manage pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and theme auto-updates right from the dashboard. After 5 months of development on the GitHub repository, user feedback (the plugin was available on the WordPress.org plugin directory), testing (which includes over 1,000 active installs), and iterating by the contributors of the #core-auto-updates team, this feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. was merged into Core in [47835] and will be released in WordPress 5.5.

A screenshot of a site’s Plugins page in the dashboard with the new “Automatic Updates” column (click to open this image in a new tab).

These new controls will allow website owners to keep their sites up-to-date and secure with less time and effort.

Note: Plugin and theme auto-updates are disabled by default. Administrators and site owners need to enable this feature to receive automatic plugin and theme updates. However, language packs for plugins and themes have always auto-updated when new updates are available. The new interface will not adjust language pack updates.

By default, all users with the update_plugins and update_themes capabilities are able to toggle auto-updates for plugins and themes respectively. On multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site installations, only networknetwork (versus site, blog) administrators have this capability, and only when in the context of the network dashboard.

A number of hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. are included for plugin authors and WordPress developers to customize the new feature to fit their needs. Let’s have a look at the available functions and hooks and how they can be used to tailor the plugin and theme auto-update experience.

New function: wp_is_auto_update_enabled_for_type()

This function indicates whether auto-updates are enabled for a given type. The two types accepted are theme and plugin.

// Check if auto-updates are enabled for plugins.
$plugin_auto_updates_enabled = wp_is_auto_update_enabled_for_type( 'plugin' );

Disable the auto-update user interface elements

It is possible to disable the new interface elements if desired. Returning false to the plugins_auto_update_enabled and themes_auto_update_enabled filters will disable the user interface elements for plugins and themes respectively. By default, these are enabled (true).

Note: This does not enable or disable auto-updates. It controls whether to show the user interface elements.

The following snippet will disable the plugin and theme auto-update UIUI User interface elements:

// Disable plugins auto-update UI elements.
add_filter( 'plugins_auto_update_enabled', '__return_false' );

// Disable themes auto-update UI elements.
add_filter( 'themes_auto_update_enabled', '__return_false' );

Modifying auto-update action links

Sometimes, a plugin or theme may want to manage updates on their own. This is common when they are not hosted on the WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ directories. For these instances, there are filters in place so plugin and theme authors can modify the auto-update related HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. output in certain locations.

Plugins screen: single site and multisite

With the plugin_auto_update_setting_html filter, it’s possible to filter auto-update column content, including the toggle links and time till next update attempt.

This filter pass the default generated HTML content of the auto-updates column for a plugin, with two additional parameters:

  • $plugin_file: The path to the main plugin file relative to the plugins directory.
  • $plugin_data: An array of plugin data.

For example, let’s say the “My plugin” plugin wants to prevent auto-updates from being toggled and its path relative to the plugins directory is my-plugin/my-plugin.php. The following example will change what is displayed within the auto-update column for that plugin:

function myplugin_auto_update_setting_html( $html, $plugin_file, $plugin_data ) {
	if ( 'my-plugin/my-plugin.php' === $plugin_file ) {
		$html = __( 'Auto-updates are not available for this plugin.', 'my-plugin' );
	}

	return $html;
}
add_filter( 'plugin_auto_update_setting_html', 'myplugin_auto_update_setting_html', 10, 3 );

Below is the result:

In the screenshot above, the default toggling action in the auto-updates column for one particular plugin has been modified using the previous example (click to open this image in a new tab).

For reference, here is the default HTML content:

<a href="…" class="toggle-auto-update" data-wp-action="…">
	<span class="dashicons dashicons-update spin hidden" aria-hidden="true"></span>
	<!-- The following text is replaced with "Disable auto-updates" when auto-updates are already enabled for this plugin -->
	<span class="label">Enable auto-updates</span>
</a>

Themes screen: single site only

Filtering the auto-update HTML content for Themes screen is a bit more tricky since this screen is rendered with a JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. template. However, it is possible to hook into this screen using the theme_auto_update_setting_template filter and returning a modified $template (the rendering template used for every theme on the Themes page).

Note: since this template is used for each theme on the page, using a conditional statement to check for the theme being targeted is highly recommended. This can be done by utilizing the data.id JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. parameter (which contains the theme slug).

Full documentation about the properties available for the theme data object is available in wp_prepare_themes_for_js() DevHub page.

The following example will replace the text auto-update HTML content for the my-theme and twentytwenty themes:

function myplugin_auto_update_setting_template( $template ) {
	$text = __( 'Auto-updates are not available for this theme.', 'my-plugin' );

	return "<# if ( [ 'my-theme', 'twentytwenty' ].includes( data.id ) ) { #>
		<p>$text</p>
		<# } else { #>
		$template
		<# } #>";
}
add_filter( 'theme_auto_update_setting_template', 'myplugin_auto_update_setting_template' );

Below is the result:

In the screenshot above, the default toggling action for auto-updates has been modified using the previous example (click to open this image in a new tab).

For reference, here is the default template output:

<div class="theme-autoupdate">
	<# if ( data.autoupdate ) { #>
		<a href="{{{ data.actions.autoupdate }}}" class="toggle-auto-update" data-slug="{{ data.id }}" data-wp-action="disable">
			<span class="dashicons dashicons-update spin hidden" aria-hidden="true"></span>
			<span class="label">' . __( 'Disable auto-updates' ) . '</span>
		</a>
	<# } else { #>
		<a href="{{{ data.actions.autoupdate }}}" class="toggle-auto-update" data-slug="{{ data.id }}" data-wp-action="enable">
			<span class="dashicons dashicons-update spin hidden" aria-hidden="true"></span>
			<span class="label">' . __( 'Enable auto-updates' ) . '</span>
		</a>
	<# } #>
	<# if ( data.hasUpdate ) { #>
		<# if ( data.autoupdate ) { #>
			<span class="auto-update-time">
		<# } else { #>
			<span class="auto-update-time hidden">
		<# } #>
		<br />' . wp_get_auto_update_message() . '</span>
	<# } #>
	<div class="notice notice-error notice-alt inline hidden"><p></p></div>
</div>

Themes screen: multisite only

On multisite installs, the Themes screen can be modified in a way similar to the Plugins screen detailed above. Using the theme_auto_update_setting_html filter, the auto-update column content can be filtered, including the toggle links and time till next update.

This filter is passed the default generated HTML content of the auto-updates column for a theme with two additional parameters:

  • $stylesheet: The directory name of the theme (or slug).
  • $theme: The full WP_Theme object.

For example, let’s say the network administrator of a multisite network wants to disallow auto-updates for the Twenty Twenty theme. The following example will change what is displayed within the auto-update column for that theme:

function myplugin_theme_auto_update_setting_html( $html, $stylesheet, $theme ) {
	if ( 'twentytwenty' === $stylesheet ) {
		$html = __( 'Auto-updates are not available for this theme.', 'my-plugin' );
	}

	return $html;
}
add_filter( 'theme_auto_update_setting_html', 'myplugin_theme_auto_update_setting_html', 10, 3 );

Blanket auto-update opt-in

If a developer wants to enable auto-updates for all plugins and/or themes (including any that are installed in the future), the auto_update_plugin/auto_update_theme filters can be used.

// Enable all plugin auto-updates.
add_filter( 'auto_update_plugin', '__return_true' );

// Enable all theme auto-updates.
add_filter( 'auto_update_theme', '__return_true' );

Note: Any value returned using these filters will override all auto-update settings selected in the adminadmin (and super admin). Changes made using these filters also will not be reflected to the user in the interface. It is highly recommended to use these filters in combination with the hooks detailed above to inform the user of the auto-update policy being enforced.

This approach will not be appropriate for all sites. It’s recommended to use the new UI to manage auto-updates unless you’re sure blanket opting-in is right for your site.

Also note: This filter was added to the codebase in WordPress 3.7.0 and is likely being used to blanket enable auto-updates for plugins and themes on sites today. If it appears the new UI elements are not changing the auto-update behavior for plugins or themes on your site, this may be why. #50662 has been opened to notify site owners that this filter is being used in Site Health.


For information, refer to the following tickets on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.: #50052, #50280.

This post is the first part of the plugins and themes auto-updates dev notesdev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include: a description of the change; the decision that led to this change a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. for WordPress 5.5.

Thanks @desrosj and @pbiron for technical review and proofreading.

#5-5, #auto-update, #auto-updates, #dev-notes, #feature-plugins, #feature-projects, #feature-autoupdates

WordPress 5.5 Core Editor Accessibility Improvements

In an effort to better communicate the specifics of what’s coming to the editor in WordPress 5.5, this post is meant to list the various accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) improvements shipping with this upcoming releaseRelease A release is the distribution of the final version of an application. A software release may be either public or private and generally constitutes the initial or new generation of a new or upgraded application. A release is preceded by the distribution of alpha and then beta versions of the software. on August 11th. Going forward, the “What’s Next in Gutenberg” posts will have clearer accessibility-related callouts to makemake A collection of P2 blogs at make.wordpress.org, which are the home to a number of contributor groups, including core development (make/core, formerly "wpdevel"), the UI working group (make/ui), translators (make/polyglots), the theme reviewers (make/themes), resources for plugin authors (make/plugins), and the accessibility working group (make/accessibility). it easier to follow relevant issues more regularly. The work to improve WordPress is never finished, and with more releases will come more improvements, but it’s encouraging to see progress in so many areas. 

Thanks to everyone who worked hard to get these improvements in place in time for 5.5! 

In most sections, explorations are shared of specific high impact improvements. Please view individual issues for more details. 

New Editor Design

WordPress 5.5 brings numerous changes to the look and feel of the editor, informed by the goal of reducing complexity by simplifying iconography, color palette, focus, and general interface. As more features are added to the blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor, a simpler and clearer design allows the interface to scale more gracefully. Examples include: the effort to create a single toolbar to have fewer tab stops, work done to make the single primary toolbar bigger (more tappable with a larger touch area), and higher contrast. Some changes, such as removing borders around selected blocks, have inspired spirited debates, and it’s been great to see so many people involved. As always, discussion, iteration, and collaboration are our best tools for moving forward together.

Keyboard Navigation Improvements

Below is a screenshot highlighting the new keyboard option mentioned above that can be found in “More tools & options > Options” modal. Checking it will stop arrow keys from navigating between blocks in edit mode. You can also programmatically auto-enable it with this code snippet: 

if ( 
  ! wp.data
      .select(‘core/edit-post’)
      .isFeatureActive(‘keepCaretInsideBlock’) 
) {
  wp.data
    .dispatch( ‘core/edit-post’ )
    .toggleFeature( ‘keepCaretInsideBlock’ );
}
Screenshot showing the “More tools & options > Options” modal where the new option lives.

The following video shows a walk-through of arrow navigation between nesting levels while in Navigation Mode mentioned in the above section: 

Video showing a walk-through of arrow navigation between nesting levels.

Screen Reader Improvements

Focus Improvements

The following video demonstrates the roving tabindex across block toolbars. Of note, the APIs to achieve this improvement in wordpress/components are listed as experimental for now and should ship in 5.6 so third-party developers can use them as well.

Video showing the roving tabindex across block toolbars.

If you’re interested in improving accessibility in the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. editor, check out the accessibility team, review the current open issues related to accessibility, provide accessibility feedback on issues, and help test GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/.

#5-5, #accessibility, #core-editor

WordPress 5.5 Planning Roundup

There have been some scattered discussions about making some shifts to the way that we manage releases. I’m open to suggestions on the timeline below if I have misunderstood anything!

As was suggested in the WP5.3 debrief, the cycle for WP5.5 has a longer alpha period (clocking in at ~126 days, one week less than WP5.3). As was discussed in the core committer Slack channel and subsequently suggested by @francina, this cycle also has a shorter RC period (clocked in at 14 day, two weeks shorter than WP5.3 but one week shorter than WP5.4).

Proposed WordPress 5.5 Schedule

These are my best guesses at the milestones, based on what I was able to find of the discussions:

  • Alpha: 3 March, 2020 trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. is open for 5.5 alpha contributions
  • Kickoff: 13 May, 2020 (that’s this post!)
  • Betas: 7 July, 2020 (8 weeks from kickoff)
  • ReleaseRelease A release is the distribution of the final version of an application. A software release may be either public or private and generally constitutes the initial or new generation of a new or upgraded application. A release is preceded by the distribution of alpha and then beta versions of the software. Candidates: 28 July, 2020 (3 weeks from betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1)
  • General Release: 11 August, 2020 (2 weeks from release candidaterelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). 1)

Proposed WordPress 5.5 Scope

The main goal for 2020 is full site editing via GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/. For WP5.5 the following features are in the suggested roadmap:

  • Update WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. to include current releases of the Gutenberg pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party.
  • Navigation menus blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. in Core.
  • Automatic updates for plugins and themes in Core.
  • Block directory in Core.
  • XML Sitemaps 
  • Lazy Loading 

Also in that roadmap are a few hopeful items. Getting these into the Gutenberg plugin would be a great goal!

There were also a collection of hoped-for tickets raised on my earlier post as well as a number from component maintainers. I ended up with some outstanding questions on those, but should have everything I need soon.

Proposed WordPress 5.5 Leads

This area is intentionally incomplete. I’ve got some more confirmations/discussions I’m working through!

  • Editor Tech:
  • Editor Design:
  • Core Tech:
  • Docs coordinator:
  • Marketing/Release Comms:
  • Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. PM:
  • Release coordinator:

#5-5 #planning

E2E (End-To-End) Testing in Core Proposal

What

E2E (End To End) tests are a form of automated software testing which runs in the context of a user using an application. The intention is to test the complete “end to end” workflow that a user would take in various scenarios.

In web software development this means running and controlling a web browser pointing at a web page, either fully automatically by a machine, or by a user following the test steps.

Frameworks for running E2E tests allow a web browser to be controlled fully automatically, for instance by navigating to URLs, filling out forms, and clicking on links and buttons. The tests operate by checking assertions about the expected content or behaviour of the page and triggering a test failure when they are not met.

Why

Testing individual aspects of an application’s code — for example with unit tests or integration tests — reduces the chance of low-level bugs in the code that powers an application. Unit testing helps maintain the quality of the code that powers the application.

In contrast, E2E testing tests the higher-level functionality of an application that the user sees, typically including the interface and the inputs and controls that the user interacts with.

Unit testing and E2E testing can, should, and do co-exist.

How

E2E tests are usually human-readable and provide logical steps for a user to perform. For example:

  • Given I am logged in as an Author
  • When I view the list of posts in the dashboard
  • And I see posts published by other users
  • Then I should not see an “Edit” link next to posts which are published by other users

The scenario above can potentially form a completely automated E2E test, depending on the framework in use and the built-in steps that have been defined for it. The tests are written in such a way that a human can follow the same steps and come to the same result.

This means anyone, not just a developer, can write an outline of an E2E test.

Implementing E2E tests in WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.

WordPress Core right now has only one E2E test in place, to check that the wp-adminadmin (and super admin) page loads. GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/, on the other hand, has quite a few.

There are some tickets and pull requests open about this:
https://core.trac.wordpress.org/ticket/43395
https://core.trac.wordpress.org/ticket/49507

There is also a test environment but it is not currently being used as part of the automated test suite: https://make.wordpress.org/core/2019/08/05/wordpress-local-environment/

It would be beneficial to create a project to work on this in a structured way in order to maintain the stability and reliability of WordPress core as new features are added and changes are made.

Moving Forward

Months ago, this topic was mentioned multiple times and @pandjarov from SiteGround has offered to set up the test environment plus some engineering time to work on the tests.

We could either set up a new one or check that the existing one is still the right way forward.

To really kick things off, the Core Team has to come up with requirements for the test environment, its tests, and the preferred workflow, so the tests are really useful.

What is needed

  • A list of requirements – I think Core Committers, especially with a long history of contributing (the so-called historians) are best suited to start the list with the most pressing concerns
  • Evaluating the existing test environment (existing vs creating new)
    Ideas about what functionality in WordPress should be a priority in the automated tests, for example, the upgrade process, or managing users, or installing plugins
  • Developers who are familiar with Jest, which is the test framework in place in Gutenberg and WordPress core, so the test environment can be improved, and to write new tests
  • A fork of the wordpress-develop repo on GitHubGitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ where the project can be managed and PRs opened
  • Volunteers to work on this. It’s a big task because it starts from 0 – this is very important because what the previous post about this has shown, in my opinion, is that an environment is not enough 😉
  • Coordination with the Test team
  • For making it easier to communicate I propose to add a dedicated weekly chat in the #core-test channel – From September 6th I am available to do that.

Deadline to comment

To makemake A collection of P2 blogs at make.wordpress.org, which are the home to a number of contributor groups, including core development (make/core, formerly "wpdevel"), the UI working group (make/ui), translators (make/polyglots), the theme reviewers (make/themes), resources for plugin authors (make/plugins), and the accessibility working group (make/accessibility). sure that the project lifts off I think it needs enough interest and volunteers to actively work on it.

Please leave a comment before September 6th (so you have a month to think about it!) with the requirements and/or (possibly AND) your availability to be part of this.

Registering default values for meta data

With WordPress 5.5, the register_meta() functions ( including register_post_meta() ) now support registering default values. Previously it was only possible to register default values for the REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. schema like this:

register_meta(
     'post',
     'greeting',
     array(
         'single'       => true,
         'type'         => 'string',
         'show_in_rest' => array(
             'schema' => array(
                 'type'  => 'string',
                 'default' => 'hello',
             ),
         ),
     )
 );

However, this would only be applied to calls made from within the REST API – calls to get_post_meta() would not use this default value. Now it is possible to pass in a default value that will be applied to all calls to any of the metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. functions, like this:

register_meta(
     'post',
     'greeting',
     array(
         'single'       => true,
         'type'         => 'string',
         'default'      => 'hello',
         'show_in_rest' => array(
             'schema' => array(
                 'type'  => 'string',
             ),
         ),
     )
 );

This brings register_meta() inline with register_setting() where it has been possible to register default values for options since WordPress 4.7.

Default values can also be paired with object sub types (introduced in WordPress 4.9.8) to limit the scope of a default value. An example of this might be if a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party registers a custom post typeCustom Post Type WordPress can hold and display many different types of content. A single item of such a content is generally called a post, although post is also a specific post type. Custom Post Types gives your site the ability to have templated posts, to simplify the concept. of product. A developer could register a default value that would only apply to the post of type product.

register_post_meta(
     'product',
     'price',
     array(
         'single'       => true,
         'type'         => 'string',
         'default'      => '0.00',
     )
 );

It is worth noting that registering a default value to a custom post type like this may have some performance overhead. To determine which post type the current post ID is, it has to load that object. See get_object_subtype for more detail. In most cases, the meta and main objects are loaded at the same time (like when using WP_Query) but if your code is doing something other than just loading meta data, it may now load the main object type too.

Non-Single Metadata

It is also possible to register not-single default values like this:

register_post_meta(
     'product',
     'price',
     array(
         'single'       => false,
         'type'         => 'string',
         'default'      => '0.00',
     )
 );

When requesting multiple values, like this:

$result = get_post_meta( 123, 'price', false );

The above code will return a numeric array with 0.00, as the first value.

Validation

When registering a default meta value the data must match the type provided. The following example will trigger a _doing_it_wrong notice as hello is not an integer.

register_meta(
     'post',
     'greeting',
     array(
         'single'       => true,
         'type'         => 'integer',
         'default'      => 'hello',
     )
 );

New filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output.

If you desire to do some really custom with default meta values, there is now a filter:

$value = apply_filters( "default_{$meta_type}_metadata", $value, $object_id, $meta_key, $single, $meta_type );

This is a dynamic filter, requiring you to add the meta type. This is an example of it’s use:

function add_my_meta_value( $value, $object_id, $meta_key, $single ){
	if( 'price' === $meta_key ) {
		if ( ! $single ) {
	   		$value = array( '0.99' );
		} else {
			$value = '0.99';
		}
	}
}
add_filter( 'default_post_metadata', 'add_my_meta_value', 10, 4 );

New functions

To makemake A collection of P2 blogs at make.wordpress.org, which are the home to a number of contributor groups, including core development (make/core, formerly "wpdevel"), the UI working group (make/ui), translators (make/polyglots), the theme reviewers (make/themes), resources for plugin authors (make/plugins), and the accessibility working group (make/accessibility). this functionality possible there are two new functions added to WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.:

  • get_metadata_raw()
  • get_metadata_default()

Now the get_metadata() function calls get_metadata_raw() and if the value is null, calls get_metadata_default(). So calling get_metadata() no longer gets the raw value, that is what get_metadata_raw() is now intended for.

More detail of the history of this change can be found in the original tracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. #43941.

Props @timothyblynjacobs, @jjj and @justinahinon for reviewing prior to publish.

#5-5, #dev-notes, #rest-api

Codebase language improvements in 5.5

Edit: 7/23/2020: A note was added to makemake A collection of P2 blogs at make.wordpress.org, which are the home to a number of contributor groups, including core development (make/core, formerly "wpdevel"), the UI working group (make/ui), translators (make/polyglots), the theme reviewers (make/themes), resources for plugin authors (make/plugins), and the accessibility working group (make/accessibility). developers aware that one of the option keys renamed prior to betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1 was renamed again after beta 3 to avoid confusion with the blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor. – @desrosj

In version 5.5, WordPress will see several changes aimed at maintaining a welcoming environment for all contributors while improving the clarity and inclusivity of the codebase. This is a separate but related effort to a recent proposal to update the default branches for all of the project’s GIT repositories.

The WordPress open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. community cares about diversity. We strive to maintain a welcoming environment where everyone can feel included, by keeping communication free of discrimination, incitement to violence, promotion of hate, and unwelcoming behavior.

WordPress Etiquette

“Whitelist” and “Blacklist”

Whitelist and blacklist are terms that specify allowed and disallowed or blocked things. However, many times when these two words are used, what is being allowed or blocked is not clear. This ambiguity can make for poor readability, and can also make it harder for non-native English speakers to understand the purpose of the variable, or how to properly translate a string.

In WordPress 5.5, these words have been removed from CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and only remain where absolutely necessary for backwards compatibility. A large percentage of the occurrences existed within inline documentation and the names of locally scoped variable, but a few instances were found in function names, option keys, action/filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same., and global variables.

While most of the changes made do not require any action to be taken, a few may need some small adjustments to plugins, themes, or custom code.

Here is what you need to know!

Renamed Options

The following options have been renamed:

  • blacklist_keys has been renamed to disallowed_keys.
  • comment_whitelist has been renamed to comment_previously_approved.

Upon upgrading to WordPress 5.5, these options will be renamed as part of the normal upgrade process and no action is required.

However, when using the Options APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. (add_option(), delete_option(), update_option(), get_option()), specifying one of the deprecated options will trigger a deprecated warning but the value for the new option name will be correctly returned.

Example

These two examples will return the same values.

$option_value = get_option( 'disallowed_keys' );

// This produces the same result, but will also trigger a deprecated warning.
$option_value = get_option( 'blacklist_keys' );

Any Options API function calls should be adjusted to look for the new option name whenever possible. For code that still needs to support support WordPress < 5.5, the following snippet will do the trick:

if ( false === get_option( 'disallowed_keys' ) ) {
    // Assume this is WP < 5.5. Option does not exist.
} else {
    // Assume this is WP >= 5.5
}

If disallowed_keys exists in the database, the stored value will be returned (which is an empty string by default, or a space separated list of keys and/or IP addresses). get_option() will return explicit false by default, which is a good indicator that the option does not exist.

There are a few things to be aware of, though.

  • Options API related filters associated with deprecated option keys will not be triggered. For example, the pre_option_blacklist_keys filter. Some basic text searches of the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party directory found that the usage of any Options API hooks specific to the two changed option keys was almost none.
  • Direct Cache API calls for these options will not be reliable. For example, wp_cache_get( 'blacklist_keys', 'options ). Instead of accessing the option directly from the Cache API, get_option() should be used instead.
  • Queries directly modifying, updating, retrieving these options form the database will potentially cause issues. This is incorrect usage and the Options API functions should always be used instead.
  • Prior to 5.5 beta 1, blacklist_keys was renamed to blocklist_keys. However, to avoid any potential confusion with block editor related features or functionality, it was renamed to disallowed_keys after 5.5 beta 3. This will be fixed automatically when updating to the next development version or installing 5.5, but any code that was changed to use blocklist_keys will need to be updated once more.

In 5.6, adding a more proper _deprecate_option() will be explored to handle future occurrences like this.

For more information, see #50413 on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress..

Deprecated functions

The following functions have been deprecated in 5.5. Though this should not cause any problems in your code, the following functions will now trigger a _deprecated_function() warning:

  • add_option_whitelist() has been replaced with add_allowed_options().
  • remove_option_whitelist() has been replaced with remove_allowed_options().
  • wp_blacklist_check() has been replaced with wp_check_comment_disallowed_list().
  • _wp_register_meta_args_whitelist() has been replaced with _wp_register_meta_args_allowed_list() (this is a private function, so should not be used outside of Core).
  • wp.passwordStrength.userInputBlacklist() was replaced with wp.passwordStrength.userInputDisallowedList() (JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/.)

For more information, see #50413 on Trac.

Deprecated actions and filters

The following action and filter hooks have been deprecated in 5.5. Any code hooked to them will still be executed. However, a deprecated warning will now be triggered. The replacement hooks will run after the deprecated hooks.

  • The whitelist_options filter hook has been replaced with allowed_options.
  • The wp_blacklist_check action hook has been replaced with wp_check_comment_disallowed_list.

For more information, see #50413 on Trac.

Deprecated global Variables

  • $whitelist_options has been replaced with $allowed_options.
  • $new_whitelist_options has been replaced with $new_allowed_options (more information below)

A scan of the plugin directory showed that only 2 plugins are explicitly accessing the $whitelist_options global and performing no modifications.

A second scan of the plugin directory showed a small number of plugins with a low amount of active installs potentially manipulating the value of $new_whitelist_options. However, it was enough to require consideration.

Because of this, the new $new_allowed_options variable is now passed by reference to the old $new_whitelist_options variable.

Unless a plugin is intentionally destroying this global variable and recreating it from scratch, this will create a seamless transition to a more inclusive name until a standardized way to deprecate a global variable can be created (such as _deprecate_global()), or the implementation can be revised to not require a global variable at all.

For more information on this change, see #50434 and #50413 on Trac.

“Webmaster”

In addition to potentially having racist undertones, the word “webmaster” has become dated and quite cryptic. One person managing all aspects of a site is, for the most part, no longer the norm. The term has also become ambiguous, potentially referring to anyone fulfilling any of the following duties involved with managing a website: web architects, web developers, site authors, website administrators, website owners, etc..

The two occurrences of this string have been replaced with alternatives that better communicate who is being referenced.

See #50394 on Trac for more information.

Props @cbringmann and @jorbin for pre-publishing review.

#5-5, #dev-notes

Merge Announcement: Extensible Core Sitemaps

This proposal seeks to integrate basic, extensibleExtensible This is the ability to add additional functionality to the code. Plugins extend the WordPress core software. XML sitemaps functionality into WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..

While web crawlers are able to discover pages from links within the site and from other sites, sitemaps supplement this approach by allowing crawlers to quickly and comprehensively identify all URLs included in the sitemap and learn other signals about those URLs using the associated metadata.

Purpose & Goals

Sitemaps help WordPress sites become more discoverable by providing search engines with a map of content that should be indexed. The Sitemaps protocol is a URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org inclusion protocol and complements robots.txt, a URL exclusion protocol.

A Sitemap is an XML file that lists the URLs for a site. Sitemaps can optionally include information about each URL: when it was last updated, how often it changes, and how important it is in relation to other URLs of the site. This allows search engines to crawl the site more effectively and to discover every public URL the site has made available. 

This core sitemaps feature aims to provide the base required functionality for the Sitemaps protocol for core WordPress objects, then enables developers to extend this functionality with a robust and consistent set of filters. For example, developers can control which object types (posts, taxonomies, authors) or object subtypes (post types, taxonomies) are included, exclude specific entries, or extend sitemaps to add optional fields. See below for the full list.

Project Background

The idea of adding sitemaps to core was originally proposed in June 2019.  Since then, development has been ongoing in GitHubGitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/, and weekly meetings in the #core-sitemaps channel started this year to push development forward. Several versions of the feature plugin have been released on the WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party repository, with the latest 0.4.1 representing the state that is considered ready to merge into core. The team is currently working on preparing the final patch to include on the Trac ticket.

Implementation Details

XML Sitemaps will be enabled by default making the following object types indexable:

  • Homepage
  • Posts page
  • Core post types (i.e. pages and posts)
  • Custom post types
  • Core taxonomies (i.e. tags and categories)
  • Custom taxonomies
  • Author archives

Additionally, the robots.txt file exposed by WordPress will reference the sitemap index.

A crucial feature of the sitemap plugin is the sitemap index. This is the main XML file that contains the listing of all the sitemap pages exposed by a WordPress site. By default, the plugin creates a sitemap index at /wp-sitemap.xml which includes sitemaps for all supported content, separated into groups by type. Each sitemap file contains a maximum of 2,000 URLs per sitemap, when that threshold is reached a new sitemap file is added.

By default, sitemaps are created for all public post types and taxonomies, as well as for author archives. Several filters exist to tweak this behavior, for example to include or exclude certain entries. Also, there are plenty of available hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. for plugins to integrate with this feature if they want to, or to disable it completely if they wish to roll their own version.

Contributors and Feedback

The following people have contributed to this project in some form or another:

Adrian McShane, @afragen, @adamsilverstein, @casiepa, @flixos90, @garrett-eclipse, @joemcgill, @kburgoine, @kraftbj, @milana_cap, @pacifika, @pbiron, @pfefferle, Ruxandra Gradina, @swissspidy, @szepeviktor, @tangrufus, @tweetythierry

With special thanks to the docs, polyglots, and security teams for their thorough reviews.

Available Hooks and Filters

Check out the feature plugin page for a full list of filters and also a few usage examples.

Frequently Asked Questions

How can I disable sitemaps?

If you update the WordPress settings to discourage search engines from indexing your site, sitemaps will be disabled. Alternatively, use the wp_sitemaps_is_enabled filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output., or use remove_action( 'init', 'wp_sitemaps_get_server' ); to disable initialization of any sitemap functionality.

How can I disable sitemaps for a certain object type or exclude a certain item?

Using the filters referred to above – check out the feature plugin page for examples.

Does this support lastmod, changefreq, or priority attributes for sitemaps?

By default, no. Those are optional fields in the sitemaps protocol and not typically consumed by search engines. Developers can still add those fields if they want to using the filters referred to above.

lastmod in particular has not been implemented due to the added complexity of calculating the last modified dates for all object types and sitemaps with reasonable performance. For a common website with less frequent updates, lastmod does not offer additional benefits. For sites that are updated very frequently and want to use lastmod, it is recommended to use a plugin to add this functionality.

What about image/video/news sitemaps?

These sitemap extensions were declared a non-goal when the project was initially proposed, and as such are not covered by this feature. In future versions of WordPress, filters and hooks may be added to enable plugins to add such functionality.

Are there any UIUI User interface controls to exclude posts or pages from sitemaps?

No. User-facing changes were declared a non-goal when the project was initially proposed, since simply omitting a given post from a sitemap is not a guarantee that it won’t get crawled or indexed by search engines. In the spirit of “Decisions, not options”, any logic to exclude posts from sitemaps is better handled by dedicated plugins (i.e. SEO plugins). Plugins that implement a UI for relevant areas can use the new filters to enforce their settings, for example to only query content that has not been flagged with a “noindex” option.

Are there any privacy implications of listing users in sitemaps?

The sitemaps only surface the site’s author archives, and do not include any information that isn’t already publicly available on a site.

Are there any performance implications by adding this feature?

The addition of this feature does not impact regular website visitors, but only users who access the sitemap directly. Benchmarks during development of this feature showed that sitemap generation is generally very fast even for sites with thousands of posts. Thus, no additional caching for sitemaps was put in place.

If you want to optimize the sitemap generation, for example by optimizing queries or even short-circuiting any database queries, use the filters mentioned above.

What about sites with existing sitemap plugins?

Many sites already have a plugin active that implements sitemaps. For most of them, that will no longer be necessary, as the feature in WordPress core suffices. However, there is no harm in keeping them. The core sitemaps feature was built in a robust and easily extensible way. If for some reason two sitemaps are exposed on a website (one by core, one by a plugin), this does not result in any negative consequences for the site’s discoverability.

#5-5, #feature-plugins, #feature-projects, #merge-proposals, #sitemaps, #xml-sitemaps