What’s New in WordPress 5.6 (Accessibility, Performance, Security)

WordPress 5.6 “Simone” is out and we’re excited to deep dive with you into the most interesting features and additions merged into Core with the latest WordPress release of 2020.

Like previous releases, WordPress 5.6 includes several versions of the Block Editor enhancing the editing experience for WordPress users who don’t have the Gutenberg plugin installed and updated on their websites yet.

Not everything is about the Block Editor, though. Several features have been added to WordPress Core, like a new default Twenty Twenty-One theme, auto-updates for major releases, better support for PHP 8.0, Application Passwords for REST API Authentication.

And there’s much more in WordPress 5.6. We’ll see accessibility improvements, UI enhancements, tons of bug fixes, and a huge list of changes for developers.

If you want to read more about WordPress 5.6 development cycle, check the links below:

Ready to dive in? Let’s go through:

What’s New with the Block Editor

With WordPress 5.6, several versions of the Gutenberg plugin have been merged into core, so WordPress users and writers should notice several improvements in the editor. We’ll see enhanced block patterns, word counts in the info panel, improved keyboard navigation, improved drag & drop UI, and much more.

For a more comprehensive list of all improvements and changes added to the block editor, check out the release announcement posts: 8.6, 8.7, 8.8, 8.9, 9.0, 9.1, and 9.2. Bug fixes and performance improvements implemented in Gutenberg 9.3 and 9.4 are also included in WordPress 5.6.

Let’s dive into the more interesting changes we’ll see in the block editor.

1. Blocks, Patterns, and UI Improvements
2. Block API V2
3. Additional Features and Improvements for Block Developers

Blocks, Patterns, and UI Improvements

New block features, enhancements, and bug fixes will improve the overall editing experience. Also, great work has been done on accessibility. Below you’ll find our handpicked selection of the most interesting features you’ll see in the block editor once you update your website to WordPress 5.6.

Position Controls for Videos in Cover Block

Added to Cover Blocks since Gutenberg 8.6, position controls for videos allow users to move the focal point around and set a custom position for videos. This functionality was previously available only for image backgrounds.

Position values are set by clicking anywhere on the focal point picker and/or using arrow keys on your keyboard. You can jump values by 10 by holding shift (see also #22531).

Block Pattern Updates

WordPress 5.6 also includes several block pattern improvements added with Gutenberg 8.6.

The layout, text, and color of the Large header and paragraph has been updated (#23858)

The heading in Two columns of text has been moved out of the text block and placed above the columns (#23853)

The Quote pattern now includes an image on top and a separator at the bottom.

A new Heading and paragraph pattern has been added with Gutenberg 8.7 (#24143).

A good usability improvement for the block inserter is the block pattern category dropdown, which allows you to filter patterns by category. This is extremely useful when you have tons of patterns to choose from (#24954).

Support for Video Subtitles

Video Blocks now support video subtitles.

Editors and content creators should provide video subtitles in WebVTT format (Web Video Text Tracks Format), which is “a format for displaying timed text tracks (such as subtitles or captions) using the <track> element” (#25861).

Once you have loaded your .vtt files, site viewers will be allowed to enable subtitles in their favorite language.

Transform Multiple Blocks into a Columns Block

An interesting usability improvement is the ability to convert multiple selected blocks into a Columns Block.

You just need to select the blocks you want to show in columns, then click the upper right button of the block toolbar.

Each selected block will be converted into a column of a Columns Block.

Background Patterns in Cover Block

Cover blocks can now display background patterns.

To add a background pattern, upload a pattern image, then toggle on the Repeated background option (here’s everything you need to know about the Media Library in WordPress).

When done, adjust the focal point picker according to your needs and try different combinations with fixed backgrounds.

Image Size Control Added to the Media & Text Block

With Gutenberg 9.1, a new image size control has been added to images in Media & Text Block.

Users can now choose from all the available image sizes (#24795).

Block API V2

A new Block API version enables blocks to render their wrapper element. The goal of the new API version is to lighten the editor’s DOM and make it match the front page content. According to Ella van Durpe:

The biggest benefit of this is that themes and plugins can more easily style the block content if the markup is the same in the editor.

The new version requires to declare the apiVersion property on block type registration:

registerBlockType( name, { apiVersion: 2 } );

The new API also requires the useBlockProps hook in the block Edit function. This hook marks the wrapper element of a block as a block element.

Any property passed to this hook will be merged and returned to the wrapper element. The following example from the dev notes shows a simple use case:

import { useBlockProps } from '@wordpress/block-editor';
 
function Edit( { attributes } ) {
	const blockProps = useBlockProps( {
		className: someClassName,
		style: { color: 'blue' },
	} );
	return <p { ...blockProps }>{ attributes.content }</p>;
}

For more examples, see Block API version 2.

Additional Features and Improvements for Block Developers

Besides the Block API Version 2, here is a list of additions for developers to go through.

Block Supports API

Block Supports API allows block developers to add features to their blocks. Colors, backgrounds, font sizes are just a few of the many features that can be added to blocks through the Block Supports API.

WordPress 5.6 also introduces several new block supports “to increase consistency and make it easier to introduce these options into blocks”.

Developers can use the new block supports adding the corresponding keys to the supports property of the block.json file or directly into the registerBlockType function.

The following example from Block Supports dev note shows how it works:

supports: {
	color: {
		background: true, // Enable background color UI control.
		gradient: true, // Enable gradient color UI control.
		text: true // Enable text color UI control.
	},
	fontSize: true, // Enable font size UI control.
	lineHeight: true // Enable line height UI control.
}

The style value will be automatically attached to the wrapper element either through the has-<value>-<preset-category> class (for preset values) or with a style element (for custom values).

For this reason, Block Supports are intended to be used with the new Block API V2.

Block Supports can be used with dynamic blocks as well.

createBlocksFromInnerBlocksTemplate API

Developers can use the InnerBlocks component to create custom blocks containing other blocks. Examples are the Columns block and the Social Links block.

The new createBlocksFromInnerBlocksTemplate Block API allows you to create blocks from the InnerBlocks template.

See dev notes for a depper view and an example of code.

Toolbar Components

A couple of changes affect the Toolbar components as well:

1. ToolbarGroup Component

Before WordPress 5.6, the Toolbar component allowed developers to group related options in a common container. Now, a new ToolbarGroup component should be used instead.

<BlockControls>
	<ToolbarGroup>
		<ToolbarButton />
	</ToolbarGroup>
</BlockControls>

2. ToolbarButton and ToolbarItem Components

Using tabbable elements directly as toolbar items (i.e. <button>) has been deprecated. Aiming to improve accessibility, toolbar items can be added using ToolbarButton for buttons and ToolbarItem for other controls. The example below shows a button and a dropdown menu:

<BlockControls>
	<ToolbarItem as="button" />
	<ToolbarButton />
	<ToolbarItem>
		{ ( itemProps ) => ( <DropdownMenu toggleProps={ itemProps } /> ) }
	</ToolbarItem>
</BlockControls>

Disabling Core Block Patterns

Core patterns can now be disabled using the core-block-patterns support flag (#24042)

Disabling Inline Image Editor

Gutenberg 8.4 added an Inline Image Editing feature allowing users to edit images directly from the Block Editor.

Developers can now disable the Image Editor using the block_editor_settings filter (#23966):

add_filter( 'block_editor_settings', function( $settings ) {
	$settings['imageEditing'] = false;
	return $settings;
} );

Reusable Blocks Moved to a Separate Package

Reusable blocks, previously part of the @wordpress/editor package, have been moved to the @wordpress/reusable-blocks package to make them available in other editors.

A New Default Theme: Twenty Twenty-One

WordPress 5.6 includes a brand new default theme. Twenty Twenty-One is a highly accessible, minimalist WordPress theme with a single column layout and a footer sidebar.

The new theme uses a system font stack and a minimal color palette based on pastel background colors.

You can read much more about Twenty Twenty-One in our in-depth blog post: Twenty Twenty-One: A Deep Dive into the New Default WordPress Theme.

Auto-Updates for Major Releases

Automatic updates are a core feature introduced in WordPress 3.7 aiming at improving site security and make it easier for site admins to maintain their WordPress websites up-to-date.

While automatic minor core updates have been implemented in earlier versions, with WordPress 5.6 site administrators can now manually enable automatic updates for major releases as well (more on that in a second).

Unfortunately, this crucial maintenance task might still be a little confusing for non-techy users. You can read more about how automatic updates work in our Deep Dive Into WordPress Automatic Updates blog post.

So, WordPress 5.6 introduces a new interface that allows site admins to enable auto-updates for major core releases.

The scope of this feature changed during WordPress 5.6 beta cycle and the original dev note has been replaced. In the words of Jb Audras,

The initial scope of Core auto-updates has moved to:

• Provide some updates to the design of the UI.
• For existing installations, the behavior will remain the same as it is today: opted-in to minor updates by default, but a user must opt-in to major updates (constants and filters that are already in use by hosts or agencies will still take precedence).
• For new installations, the default behavior will change: opted-in to minor updates by default and opted-in to major updates by default.

Starting with WordPress 5.6, you can opt-in to automatic updates for major core versions in the Updates screen, where a new UI provides a checkbox allowing you to Enable automatic updates for all new versions of WordPress.

Once you have enabled core auto-updates for major releases, you can then enable them to trigger for maintenance and security only by clicking on Switch to automatic updates for maintenance and security releases only.

Major Automatic Core Updates for Developers

First, when major core automatic updates are enabled, the auto_update_core_major option is stored in the database with the option_value enabled. So, if get_site_option( 'auto_update_core_major' ) returns true, the automatic updates checkbox is checked.

Then WordPress checks if major core auto-updates are enabled through the WP_AUTO_UPDATE_CORE constant or allow_major_auto_core_updates filter and sets the checkbox accordingly.

Developers can also disable major core auto-updates by setting the WP_AUTO_UPDATE_CORE constant to false or minor as shown below (see also Controlling Background Updates Through wp-config.php):

# Disables all core updates:
define( 'WP_AUTO_UPDATE_CORE', false );

# Enables minor updates:
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Note that possible values for WP_AUTO_UPDATE_CORE are true (all), 'beta', 'rc', 'minor', false.

Another option to disable major core auto-updates by default is using the new allow_major_auto_core_updates filter:

add_filter( 'allow_major_auto_core_updates', '_return_false' );

A Few Comments on Adding Auto-Updates to Core

Back in December 2018, Matt Mullenweg shared the nine priorities for 2019 where “Providing a way for users to opt-in to automatic updates of major Core releases” was number 7. Maybe a bit late, but we are getting there.

Major automatic core updates should have a great impact on WordPress security and overall experience. One thing seems to be clear: from a technical standpoint, the major automatic core updates feature is a complex task that’s not 100% accomplished with the release of WordPress 5.6.

After a thoughtful discussion on Slack, Josepha Haden summarized the concerns and questions coming from Core contributors.

The main long-term goal is to have auto-updates available in the majority of WordPress websites to improve security across the whole WordPress ecosystem (more than 30% of the web).

Anyway, according to Helen Hou-Sandí, Core Lead Developer:

In my mind there are some very difficult technical things to execute on and this needs some VERY disciplined and focused technical product ownership

So we should see additional changes and improvements to the major automatic core updates UI over time. This is what we may expect from now on:

WordPress 5.6:

• In existing installations, major updates must be enabled by the user. Any constant and filter already in use will take precedence. Minor updates are enabled by default.
• In new installations, both minor and major updates are enabled by default.

WordPress 5.6.1:

• We should see some changes to the core auto-updates UI based on feedback.

WordPress 5.7:

• A nudge should be added to the Site Health screen for anyone who opted-out of major auto-updates.
• An auto-updates opt-in should be added to the installation process in WordPress 5.7.

A big concern with core auto-updates is the trust of users. According to Helen:

I believe that we can still do a lot of work to proactively solicit the trust of users, especially those who have had previous bad experiences with WordPress and/or updates

However, each WordPress website is a mix of Core, plugins, and theme. In the words of Helen:

Core updates are broadly pretty safe and there are some protections built-in, but as sites can run any code from any source, there’s no such thing as “100%” for “every kind of WordPress website”.

Users with core auto-updates enabled should regularly back-up their websites or choose a web host providing automatic backups in their plans.

Core auto-updates will also affect the overall update experience, including plugin and theme automatic updates. Joost de Valk noted in a comment:

If we enable WordPress core auto-updates by default, we should do the same for plugins. Otherwise, plugins and themes can’t update for things they need to fix because of core updates. I think users would also expect this: if WordPress auto-updates, plugins and themes should auto-update too.

Site Health Changes in WordPress 5.6

Along with all the features here discussed, WordPress 5.6 also brings an improved version of the Site Health tool, which now behaves differently in the background.

Site Health Check Data Validation

A validator now checks issue responses for Site Health tests. The validator will discard any invalid response, preventing the Site Health tool from causing fatal errors and halting any further controls.

From now on, invalid responses won’t affect the Site Health indicator (#50145).

Asynchronous Checks via REST Endpoind

The Site Health tool is a powerful security tool that allows site owners to be aware of the health status of their websites.

This tool executes a number of security tests providing an overview of your website’s health status.

These tests fall into two categories: direct tests, running on page load, and async tests, which may require some time to complete, and will run later via JavaScript calls.

Previously, these tests were executed with a call to admin-ajax.php. With WordPress 5.6, things are moving away from admin-ajax.php and a new REST API endpoint will be used instead. Starting in WordPress 5.6, asynchronous tests can be found under the /wp-json/wp-site-health/v1 namespace.

Thanks to the new REST API enhancement, plugins and themes are also able to make use of REST endpoints and are not limited to Ajax actions for their health tests.

Each asynchronous test can now declare the has_rest argument, which defaults to false.

The code below from wp-admin/includes/class-wp-site-health.php shows the array of asynchronous tests in WordPress 5.6:

'async'  => array(
	'dotorg_communication' => array(
		'label'             => __( 'Communication with WordPress.org' ),
		'test'              => rest_url( 'wp-site-health/v1/tests/dotorg-communication' ),
		'has_rest'          => true,
		'async_direct_test' => array( WP_Site_Health::get_instance(), 'get_test_dotorg_communication' ),
	),
	'background_updates'   => array(
		'label'             => __( 'Background updates' ),
		'test'              => rest_url( 'wp-site-health/v1/tests/background-updates' ),
		'has_rest'          => true,
		'async_direct_test' => array( WP_Site_Health::get_instance(), 'get_test_background_updates' ),
	),
	'loopback_requests'    => array(
		'label'             => __( 'Loopback request' ),
		'test'              => rest_url( 'wp-site-health/v1/tests/loopback-requests' ),
		'has_rest'          => true,
		'async_direct_test' => array( WP_Site_Health::get_instance(), 'get_test_loopback_requests' ),
	),
	'authorization_header' => array(
		'label'     => __( 'Authorization header' ),
		'test'      => rest_url( 'wp-site-health/v1/tests/authorization-header' ),
		'has_rest'  => true,
		'headers'   => array( 'Authorization' => 'Basic ' . base64_encode( 'user:pwd' ) ),
		'skip_cron' => true,
	),
),

Scheduled Site Health checks:

While asynchronous tests have been implemented to prevent slow page loads and timeouts, such concern does not exist with scheduled tests.

With that in mind, in addition to the has_rest argument we mentioned above, test arrays can also declare the async_direct_test argument (using the code above), which should be a callable instance of a test.

If a test is run during a scheduled event, the test won’t use the REST API endpoint but will run directly.

Application Passwords for REST API Authentication

Application Passwords is a new system for making authenticated requests to various WordPress APIs.

Passwords are 24-characters long and consist of upper-case, lower-case, and numeric characters, that can be generated either manually or through the REST API.

To manually generate a new application password, browse to your Profile screen and scroll down the page.

Choose a name for your Application Password and confirm. WordPress will display your new password.

Application passwords are displayed in 4-character chunks, separated by spaces, as shown below:

gsUc UhkU 0ScI gdRd TGoU vrW5

However, passwords can be used with or without spaces:

The application passwords passed back through the authorization flow do not include spaces. They are strictly there to make it easier for someone staring at a long string to keep their place if manually entering it.

They can be used chunked, without spaces, or — heck — if you wanted to, you could probably add a space after every character.

In the User Profile screen, you can view, create, and revoke application passwords. Last Used and Last IP columns make you easily find out passwords no longer used that should be revoked.

At the time of this writing, Application Passwords can be used with REST API authenticated requests and with the legacy XML-RPC API. However, we should see Application Passwords used with additional APIs in the future. George Stephanis explains:

The application passwords authentication scheme can also be applied to future APIs for WordPress as they become available. For example, if GraphQL or other systems are enabled in WordPress, application passwords will provide them with a solid, established authentication infrastructure to build off of out of the box.

Using Application Passwords on wp-login.php is not possible.

For a closer view of this feature and more technical insights, make sure to check the following resources:

Better Support for PHP 8

PHP 8.0 brings in tons of new features and optimizations making it a true milestone within the evolution of the language. The newer version of PHP introduces many updates breaking backward compatibility and many deprecated features have now been officially removed. So, adding support for PHP 8 in WordPress is a great challenge.

In fact, even if WordPress Core contributors put great efforts into making WordPress 5.6 compatible with PHP 8, we shouldn’t expect that every possible issue would be discovered. The goal here is to reach a point where the whole WordPress ecosystem is compatible with PHP 8, which seems really a tough nut to crack at the moment.

Furthermore, a WordPress website includes at least one theme and a variable number of plugins. So, what we may expect is good support for PHP 8 in WordPress Core, but it’s hard to believe that plugins and themes would quickly add support for PHP 8.

We agree with Jonathan Desrosiers when he states:

The state of PHP 8 support within the broader ecosystem (plugins, themes, etc.) is impossible to know. For that reason, WordPress 5.6 should be considered “beta compatible” with PHP 8.

“Beta compatible with PHP 8” seems a good expression to represent an ongoing process that still requires a lot of effort, but at the same time acknowledges the great work done so far.

However,

All plugin and theme developers, as well as hosting communities, are called on to make their code compatible with PHP 8. This will allow WordPress to attain truly “full compatibility” sooner, and without end-users having to carry the burden.

Some PHP 8 Changes to Be Aware Of

As we mentioned above, making WordPress fully compatible with PHP 8 is a work in progress. Jonathan Desrosiers provides a list of PHP 8 features and changes WordPress developers should be aware of.

Named Parameters

With PHP named arguments is now possible to pass arguments to a function based on the parameter name, rather than the parameter position. This allows to write code that is self-documenting, arguments are order-independent, and default values can be arbitrarily skipped.

Unfortunately, currently named parameters may cause backward compatibility issues in WordPress. The main reason is that parameter names are subject to change without notice until the current audit is completed. So, at the time of this writing:

Using named parameters when calling WordPress functions and class methods is explicitly not supported and highly discouraged until this audit can be completed, as during the audit, parameter names are subject to change without notice. When this audit has been completed, it will be announced in a future developer note.

Strict Type/Value Validations for Internal Functions

When passing a parameter of illegal type, internal and user-defined functions behave differently. User-defined functions throw a TypeError, but internal functions behave in a variety of ways, depending on several conditions.

To remove these inconsistencies, in PHP 8 the internal parameter parsing APIs always generate a ThrowError in case of a parameter type mismatch.

Strict type declaration is not used in WordPress Core. However, Core contributors are working to prevent invalid types to be passed to Core functions. Until that work is completed, this PHP 8 change may lead to TypeErrors, “especially if a value’s type is incorrectly changed through code hooked to a filter”.

Stricter Type Checks for Arithmetic and Bitwise Operators

In previous versions of PHP, using arithmetic and bitwise operators to an array, resource, or non-overloaded object was allowed, but the behavior was inconsistent and even unreasonable sometimes:

var_dump([] % [42]);
// int(0)

With PHP 8, the behavior is always the same and all arithmetic and bitwise operators will throw a TypeError exception when the operand is an array, resource, or non-overloaded object (see the RFC).

This is another change which requires some extra work from Core contributors, like the many errors, warning, and notice changes.

Again, due to the several issues still unresolved, it’s highly recommended to run compatibility tests on a staging or development environment before you make the switch to PHP 8 on your live website. Read more about WordPress and PHP 8.0.

Additional Changes for Developers

WordPress 5.6 introduces tons of changes for developers and we couldn’t include all in our list. But here the top 3 we think are worth looking at:

1. wp_after_insert_post Action Hook

Before WordPress 5.6 you could use save_posts or similar actions to run custom code after a post was published. Now WordPress 5.6 introduces the new wp_after_insert_post action hook, which fires only once terms and metadata have been saved.

In addition, several functions have been updated to prevent those hooks from being fired. The new $fire_after_hooks parameter has been added to the wp_insert_posts(), wp_update_post() and wp_insert_attachment() functions. If set to false, it prevents the after insert hooks to be fired.

Check out the dev note for a deeper overview.

2. Typecasting

Typecasting functions intval(), strval(), floatval() and boolval() have been removed from Core in favor of direct typecasting:

1. intval() → (int)
2. strval() → (string)
3. floatval() → (float)

This change has direct effects on performance as direct typecasting is ~6x faster than typecasting functions.

3. WP_Error Objects

The WP_Error class has been enhanced to allow merging multiple WP_Error instances into one. Previously you could do that only manually. Now, WordPress 5.6 introduces three new methods to help handle multiple WP_Error instances. The code below is an example from the dev note:

<?php
$error_1 = new WP_Error(
	'code1',
	'This is my first error message.',
	'Error_Data'
);
 
$error_2 = new WP_Error(
	'code2',
	'This is my second error message.',
	'Error_Data2'
);
 
// Merge from another WP_Error.
$error_1->merge_from( $error_2 );
 
// Retrieve all error data, optionally for a specific error code.
$error_1->get_all_error_data( 'code2' );
 
// Export to another WP_Error
$error_1->export_to( $error_2 );

Further Readings for Developers

It’s impossible to mention all changes focused on development introduced by WordPress 5.6, but you can read more about them using the following resources:

Summary

WordPress 5.6 is a major release with tons of features and changes for both users and developers. We are always excited to see how the evolution of web technologies directly affects WordPress security, performance, usability, and accessibility.

But evolution never stops and we can already take a peek at future potential release dates.

Up to you now: What do you like the most in WordPress 5.6? And what features would you like to be added to WordPress 5.7?