What’s New in WordPress 5.7 (Lazy-Loading, HTTPS, UI Updates, New APIs, & More)

We’re accustomed to seeing small and not-so-small changes and new features added to WordPress Core every time a new version is released. WordPress 5.7 is no exception, and it’s great to see how each new release brings us a little closer to the Big Picture.

With several versions of the Block Editor merged into Core, the new release improves the overall editing experience and enables developers to build more advanced blocks and add more powerful customizations to the block editor.

Aside from the editor, WordPress 5.7 also introduces tons of changes and great features, including lazy-loading iframes, login and registration interface updates, reset password links, a vast number of bug fixes, and much more.

We’ve run our tests on DevKinsta, and we’re ready to share with you our favorite features and changes that are coming with WordPress 5.7—complete, of course, with tons of screenshots and code snippets.

If you want to dive deeper into the first major release of 2021, check out the WordPress 5.7 Development Cycle, Planning Roundup, and Field Guide.

So, while we continue to wait for Full Site Editing (in Core by WordPress 5.8), let’s get comfortable and enjoy what’s new in WordPress 5.7!

What’s New in the Block Editor

WordPress 5.7 brings many versions of the Gutenberg plugin to Core. It would be impossible to mention all those additions here on top of the many changes and bug fixes added to the editor, but you can visit the following links to deep-dive into each version: 9.3, 9.4, 9.5, 9.6, 9.7, 9.8, 9.9.

Bug fixes and performance improvements from Gutenberg 10.0 and 10.1 are also part of WordPress 5.7.

That said, let’s go through our hand-picked list of the most exciting features and changes added to the block editor with WordPress 5.7:

Block Variations Features, Enhancements, and APIs

Introduced with WordPress 5.4, block variations provide a way for the user to select a different instance of the same block.

This feature works in tandem with the Block Variations API, a powerful tool that allows developers to add, manage, or remove variations of blocks.

WordPress 5.7 introduces several enhancements, features, and new APIs for block variations, providing a better UI and more powerful tools for developers. Let’s dive in.

Block Variation Transformations

First introduced with Gutenberg 9.4 and now added to WordPress 5.7, a Transform to variation switcher appears below the block card for blocks supporting this feature.

When registering a new block variation, block developers can add the variation switcher to the block inspector by adding the new transform option to the block variation scope field, as shown in the following example (JS code only):

wp.blocks.registerBlockVariation( 'core/heading', { 
	name: 'green-text', 
	title: 'Green Text', 
	description: 'This block has green text. It overrides the default description.',  
	attributes: { 
		content: 'Green Text', 
		textColor: 'vivid-green-cyan' 
	}, 
	icon: 'palmtree', 
	scope: [ 'inserter', 'transform' ] 
} );

In this example, a block variation appears in two areas of the editor’s UI—the block inserter and the block inspector.

For an in-depth overview of Block Variation Transformations, see also PR #26687.

Block Information Now Matches Block Variations

Since WordPress 5.7 (and Gutenberg 9.7), the UI shows more specific information about block variations, whereas it showed only generic information previously.

Embed blocks and Social Icons are built as block variations; they provide good examples of WordPress matching block information with block variations.

These changes affect the block inspector, the block navigation bar, and the breadcrumbs. Since Gutenberg 9.8, this UI enhancement also applies to the block switcher.

New Block Variations APIs

WordPress 5.7 also introduces new APIs developers can use on block variation registration to show a block variation’s correct information (Gutenberg 9.7).

The new isActive property is a function that accepts a block’s attributes. You can use the variation’s attributes to determine if a variation is active (see also Block API Reference).

Block developers can use this function to display variation information instead of block information. One example could be the embed block, where we can change the providerNameSlug attribute’s value (an example from the dev note):

const variations = [
{
	name: 'wordpress',
	title: 'WordPress',
	keywords: [ __( 'post' ), __( 'blog' ) ],
	description: __( 'Embed a WordPress post.' ),
	attributes: { providerNameSlug: 'wordpress' },
	isActive: ( blockAttributes, variationAttributes ) =>
		blockAttributes.providerNameSlug === variationAttributes.providerNameSlug,
},
];

In the following example, the isActive property is used to change the color attribute:

variations: [
{
	name: 'blue',
	title: __( 'Blue Quote' ),
	isDefault: true,
	attributes: { color: 'blue', className: 'is-style-blue-quote' },
	icon: 'format-quote',
	isActive: ( blockAttributes, variationAttributes ) =>
		blockAttributes.color === variationAttributes.color
},
],

The new useBlockDisplayInformation hook returns information about a given block. The new hook takes into account the isActive property of a block variation and returns the block’s title, icon, and description.

These changes affect Block Card (Inspector Tools), Navigation List View (top bar), and Breadcrumbs (see also PR #27469).

New Buttons Block Features

A couple of new features improve the Buttons block functionality and interface.

Button Dimensions

A new control available in Settings Sidebar now allows us to set a percentage width for buttons housed in Buttons blocks (Gutenberg 9.4).

Just select a button and choose 25%, 50%, 75%, or 100%. Percentages refer to the parent container. The image below shows different combinations of button dimensions.

For more technical insights, check out pull requests #25999 and #26781.

Vertical Layout

This new feature adds variations for vertical orientation to the Buttons block. Users can switch from a horizontal layout to a vertical one using the Transformations switcher available in the block settings panel (Gutenberg 9.6).

Social Icons Enhancements

WordPress 5.7 adds new customization options to Social Icons: custom size support and custom colors.

Social Icons Size

With the Social Icons block selected, the block toolbar now provides a Size option menu with available sizes (Gutenberg 9.4).

Custom Colors in Social Icons

The same block now supports color settings, allowing us to set different custom colors for icons and backgrounds (Gutenberg 9.9).

You can now use the theme’s color palette for Social Icons, preventing icon colors from clashing with your website’s color scheme (see also PR #28084).

Font Size Support

WordPress 5.7 adds font size support for both List and Code blocks.

Font Size in List Block

A typography card with controls for font size has been added to the List block settings (Gutenberg 9.4).

Users can pick one of the available font sizes for list items or set a custom font size expressed in pixels. The “Reset” button restores default values.

Font Size Support in Code Block

WordPress 5.7 also adds support for font size management within Code blocks. With a Code block selected, the block settings sidebar displays a new Font size control. This control allows you to either pick one of the preset sizes available in your theme or set a custom value in pixels (Gutenberg 9.5).

This feature’s implementation also allows using global style variables in the CSS of Code blocks (see also PR #27294). The image below shows a Code block on the frontend with the Twenty Twenty theme installed.

Full Height Alignment in Cover Block

WordPress 5.7 introduces a new Full Height Toolbar Alignment component. It was first added to the block editor with Gutenberg 9.5. Now, it’s merged into Core and implemented in the Cover block.

If you toggle the block toolbar button, keeping an eye on the minimum height control, you’ll see that the full-height alignment is just a shorthand for 100vh (read more on viewport-percentage lengths).

You can use Full Height Alignment in combination with other control settings like fixed background, content position, and so on. You’ll probably be surprised by the number of impressive effects you’ll be able to create on your pages.

Drag & Drop Blocks and Patterns from the Inserter

The block inserter now supports drag & drop for blocks and patterns. Users can grab any block or pattern from the inserter and place it anywhere on the post canvas (Gutenberg 9.6 and 9.7).

Note that drag & drop only works if your theme supports block patterns.

Semi-transparent Spacer Block

In place of the former opaque gray color, the Spacer block now has a semi-transparent background (Gutenberg 9.8).

This feature should make it easier to identify the Spacer block on top of any background color.

Additional Improvements in the Block Editor Worth Mentioning

Our list won’t cover all features and enhancements merged into Core, so be sure to check the official documentation and dev notes for a more comprehensive register of what’s new in the block editor with WordPress 5.7.

But just to name a few others, in 5.7, you’ll also find:

Lazy-Loading iframes

Lazy loading is an optimization technique that defers loading non-critical resources until they are in the user’s viewport. Lazy-loading images and embedded resources aren’t downloaded and rendered until they’re needed. It can significantly improve site performance, especially for websites sporting high-resolution images and videos.

Before native lazy loading, developers could only lazily load assets via JavaScript. WordPress users were forced to use a plugin to achieve the same effect. Since lazy loading became a standard, though, images and iframes can be lazy-loaded by merely adding the loading="lazy" attribute to img and iframe tags.

WordPress 5.5 introduced Native Image Lazy-Loading in WordPress Core, automatically adding the loading="lazy" attribute to img tags with width and height attributes specified.

Now, since WordPress 5.7, lazy loading is extended to iframe tags. As for images, to prevent layout shifting, loading="lazy" will be only added to those iframe tags having width and height attributes specified.

In WordPress, native lazy-loading works with iframes in the following contexts:

• iframes in post content (the_content)
• iframes in post excerpts (the_excerpt)
• iframes in text widgets (widget_text_content)

In WordPress, the majority of iframes rely on the oEmbed integration, which automatically transforms a URL into the corresponding iframe tag. Unfortunately, not every web service provides width and height attributes for iframes; this prevents WordPress from adding the loading attribute to those iframes.

The image below shows an iframe tag with the loading="lazy" attribute:

In the words of Felix Arntz:

The markup of those iframe tags is controlled by the respective web service, and only some of those web services follow the best practice of providing width and height attribute. Since WordPress cannot guess the dimensions of the embedded resource, the loading="lazy" attribute will only be added if the oEmbed iframe tag comes with both dimension attributes present.

The following image shows an iframe tag without the loading="lazy" attribute:

Lazy-Loading iframes for Developers

From a developer’s perspective, the new feature required several changes, including:

• The wp_filter_content_tags() function behavior has been extended to add the loading attribute to iframe tags. The loading attribute was previously only added to img tags.
• By default, the wp_lazy_loading_enabled() function now returns true for iframe tags (when enabled).
• The new wp_iframe_tag_add_loading_attr() function allows for the addition of the loading attribute to iframe tags (similar to wp_img_tag_add_loading_attr()—see Code Reference).
• The wp_iframe_tag_add_loading_attr filter allows for the customization of lazy loading on specific iframes. Returning false or an empty string will not add the attribute.

You can override the default behavior using the existing wp_lazy_loading_enabled filter, which now returns true for iframe tags.

add_filter(
	'wp_lazy_loading_enabled',
	function( $default, $tag_name, $context ){
		if ( 'iframe' === $tag_name && 'the_content' === $context ){
			return false;
		}
		return $default;
	},
	10,
	3
);

You can also use the new wp_iframe_tag_add_loading_attr filter, which permits the customization of a specific iframe tag’s behavior. For example, you could disable lazy loading for YouTube videos in a particular context.

The code below is based on an example from the dev note and shows how to disable lazy loading for iframes embedding YouTube videos:

add_filter(
	'wp_iframe_tag_add_loading_attr',
	function( $value, $iframe, $context ){
		if ( 'the_content' === $context && false !== strpos( $iframe, 'youtube.com' ) {
		return false;
	},
	10,
	3
);

Note that all web browsers do not generally support lazy loading at the time of this writing. You can see below that Firefox and Safari only support lazy loading on images.

One-Click Site Migration from HTTP to HTTPS

Since 5.7, WordPress will detect if a website’s environment supports HTTPS. If so, the HTTPS Status section in the Site Health tool provides a call-to-action button allowing site admins to switch their websites from HTTP to HTTPS with a single click. The site content is migrated on the fly, saving us from running into any mixed content warnings.

WordPress will display a notification if HTTPS is not supported.

HTTP to HTTPS Migration for Developers

Along with the new automatic feature accessible from the Site Health tool, WordPress 5.7 introduces new functions enabling developers to test and customize different aspects of HTTPS detection and migration.

The new wp_is_using_https() function returns true if both “Site Address” (home_url()) and “WordPress Address” (site_url()) have a URL containing https. This new feature is illustrated clearly by Felix Arntz in the dev note:

Essentially, changing both of these URLs to HTTPS formally indicates that the site is using HTTPS. While there are other ways to enable HTTPS partially in WordPress (e.g. with the FORCE_SSL_ADMIN constant), the new detection mechanism focuses on using HTTPS throughout the entire site, i.e. its frontend and backend.

While the wp_is_using_https() function checks for the presence of https in the URL, wp_is_https_supported() checks if the site environment correctly supports HTTPS.

This function essentially checks for the presence of the https_detection_errors option in the database and returns true if no errors are detected. In case your environment does not support HTTPS, the https_detection_errors option will be present in the wp_options table, as shown in the following image:

As mentioned above, hardcoded URLs in site content are changed on the fly, all thanks to two new functions: wp_replace_insecure_home_url() and wp_should_replace_insecure_home_url().

To migrate a website from HTTP to HTTPS, the site admin would only need to manually update “Site Address” and “WordPress Address” to include HTTPS instead of HTTP. However, to make things even easier, WordPress 5.7 introduces the new wp_update_urls_to_https() function.

This latter function allows for the migration of a site and all its content from HTTP to HTTPS with a single click (at least in the most common scenarios, such as when “Site Address” matches “WordPress Address”). It’s an absolute novelty and a considerable improvement in the WordPress administration experience.

For more technical aspects of HTTPS detection and migration, see Felix Arntz’s dev note, as well as tickets #47577 and #51437.

New Post Parent Related Functions

WordPress 5.7 introduces two new Post Parent related functions. They’re simple to use and help you reduce the logic in plugins and themes.

has_parent_post()

The has_parent_post() function is a conditional tag that checks if a given post has a parent, then returns true or false accordingly. It accepts post ID or WP_Post object as a parameter, and uses the $post global variable if available. See the following example:

<?php if ( has_parent_post( get_the_ID() ) ) : ?>
	// your code here
<?php endif; ?>

get_parent_post()

The get_parent_post() function is a template tag that retrieves the parent WP_Post object for a given post. Like the previous function, it accepts post ID or WP_Post object as a parameter. See the following example of usage:

<a href="https://kinsta.com/blog/wordpress-5-7/<?php the_permalink( get_parent_post( get_the_ID() ) ); ?>"><?php echo get_the_title( get_parent_post( get_the_ID() ) ); ?></a>

In the real world, we would use these functions in conjunction. You can run a test by yourself by adding the following code from the dev note to the single.php template file of your theme:

<?php if ( has_parent_post( get_the_ID() ) ) : ?>
	<p><a href="https://kinsta.com/blog/wordpress-5-7/<?php the_permalink( get_parent_post( get_the_ID() ) ); ?>">
	<?php
		echo sprintf(
			esc_html__( 'Parent page: %s', 'text-domain' ),
			get_the_title( get_parent_post( get_the_ID() ) )
		);
	?>
	</a></p>
<?php endif; ?>

Login and Registration Interface Updates

WordPress 5.7 brings several improvements to the login and registration feature, with an improved Reset Password interface, new hooks, and other minor changes.

Reset Password Screen

The Reset Password screen now provides two buttons: Generate Password and Save Password. The first button generates a new strong password at each click, while the second button saves your password. This change should result in an improved password reset experience for new WordPress users.

The image below compares Reset Password screens in WordPress 5.6 and 5.7:

New Filters

The new lostpassword_user_data hook lets us filter the $user_data variable on password reset. Developers can now perform user validation using custom data instead of a username or email address. For a real-world example, check out this comment from Marcelo Villela Gusmão.

The new login_site_html_link filter hook allows us to completely replace the HTML generating the “Back to {site_name}” link with custom code/link. Now developers can set custom text for the link, as well as change the link itself. You can use the filter as illustrated in the following example:

function custom_login_site_html_link( $link ) {
	return '<a href="' . esc_url( home_url( '/blog/' ) ) . '">' . __( 'Back to my awesome blog', 'textdomain' ) . '</a>';
}
add_filter( 'login_site_html_link', 'custom_login_site_html_link', 10, 1 );

The image below shows the output on the screen:

For additional changes, check the Login & registration screens changes in WordPress 5.7 dev note.

New Functions to Check if a Post is Publicly Viewable

WordPress 5.7 introduces two new functions enabling developers to check if a post is publicly viewable.

is_post_status_viewable()

The new is_post_status_viewable() function lets developers determine if a post is publicly viewable depending on the post status.

This new function provides a better way to check if a post is viewable than the existing is_post_type_viewable() function, which can check if a post type is visible to anonymous users but doesn’t help to determine if a specific post is viewable or not.

For built-in post types, is_post_status_viewable() checks the public attribute. For custom post types, it checks the publicly_queryable attribute instead.

We tested the following code, based on the example from the dev note, in a local install:

$current_post_status = get_post_status( $post );
if ( is_post_status_viewable( $current_post_status ) ) {
	echo '<p>This post uses a public post status.' . ' Current status: <strong>' . $current_post_status . '</strong></p>';
} else {
	echo '<p>This post uses a non public post status.' . ' Current status: <strong>' . $current_post_status . '</strong></p>';
}

is_post_status_viewable() accepts one required parameter:

• $post_status (string|stdClass) The post status name or object.

In a public blog post, the code above would produce the following result:

In a private post, the result would be the following:

Jean-Baptiste Audras, the author of the dev note, warns:

Please note that password-protected posts are considered publicly viewable, while private posts are not.

is_post_publicly_viewable()

The new is_post_publicly_viewable() function returns true if both is_post_status_viewable() and is_post_type_viewable() return true. It also lets us determine if a specific post is publicly viewable (i.e. whether it’s viewable to logged-out users).

is_post_publicly_viewable() accepts one optional parameter:

• $post (string|stdClass) A post ID or object. By default, the global $post object is passed.

A New Dynamic Hook to Filter the Content of a Specific Block Type

WordPress 5.7 introduces a new dynamic hook that enables developers to filter the content of a specific block type.

This fresh render_block_{$this->name} filter is similar to the existing render_block filter, with one key difference: render_block filters the content of a single block, while the new dynamic hook filters the content of block type {$this->name}.

To use this filter, you should provide the following parameters:

• $block_content (string): The block content to be appended.
• $block (array): The full block, including name and attributes.

The callback returns the modified block content.

The following example shows a case use for this filter on a paragraph block:

add_filter( 
	'render_block_core/paragraph', 
	function( $block_content, $block ) {
		$content="<div class="my-custom-wrapper">" . $block_content . '</div>';
		return $content;
	}, 
	10, 
	2 
);

In this example, the core/paragraph suffix is the core paragraph block type’s slug. For custom blocks, the slug should be something like my-custom-plugin/my-custom-block.

See the dev note for a more in-depth overview and additional examples of use.

New Robots API

The robots meta tag allows site owners to control how a web page should be indexed and served to users in search engine results (btw, make sure to check out our guide on WordPress SEO).

WordPress 5.7 introduces a new Robots API allowing developers to control this robots meta tag. The new API provides a wp_robots filter for theme developers to add their custom directives to the robots meta tag.

Additionally, the max-image-preview:large directive is now added by default to websites configured to be visible by search engines. It instructs search engines to display large image previews in search results.

Developers can remove the max-image-preview:large directive using the following code:

remove_filter( 'wp_robots', 'wp_robots_max_image_preview_large' );

Customizing the robots directives is pretty straightforward. The following example from the dev note shows how to add a custom directive to the meta tag:

add_filter( 
	'wp_robots', 
	function( $robots ) {
		$robots['follow'] = true;
		return $robots;
	}
);

The code above would produce the following output:

<meta name="robots" content="max-image-preview:large, follow">

It’s also possible to remove existing directives simply by unsetting values. The following code disables the max-image-preview directive:

function my_wp_robots_directives( $robots ) {
	unset( $robots['max-image-preview'] );
	$robots['follow'] = true;
	return $robots;
}
add_filter( 'wp_robots', 'my_wp_robots_directives' );

You’ll find an in-depth overview of the robots meta tag on Ahrefs blog and Google Search reference. See the dev note for additional information about the new WordPress Robots API and deprecated functions.

Reset Password Links

A new feature now allows site admins to send reset password links via email to any registered user. This feature could be useful if a user cannot access the reset password link for any reason.

Site admins can send a reset password link via email from different areas. First, you’ll find a new section providing a Send Reset Link button in any user Profile Screen.

If everything goes well, you should see an admin notice confirming that the password reset link was emailed to the user.

You can also send a password reset link from the Users Screen.

You can even select several users and send password reset links in bulk.

As mentioned earlier, users will receive an email containing a password reset link. The following image shows a password reset email in the DevKinsta Email Inbox tool.

Developers can use retrieve_password_title and retrieve_password_message filters to customize the email’s subject and message.

Additional Enhancements for Developers

New Functions to Pass Attributes to Script Tags

Several new functions now permit the passing of attributes to <script> tags (i.e. async or nonce).

wp_get_script_tag()

wp_get_script_tag() loads a formatted script tag and automatically injects the type attribute if the theme has not declared support for HTML5 script tags. It accepts an array of key-value pairs representing the attributes being added to the <script> tag.

This function pairs with the new wp_script_attributes filter, which can be used to filter attributes.

wp_print_script_tag()

wp_print_script_tag() prints a formatted script tag.

wp_get_inline_script_tag()

wp_get_inline_script_tag() wraps inline JavaScript in a script tag.

This function has a corresponding wp_inline_script_attributes hook that filters attributes to be added to a script tag.

wp_print_inline_script_tag()

wp_print_inline_script_tag() prints inline JavaScript in a script tag.

wp_sanitize_script_attributes()

The new wp_sanitize_script_attributes() function is used to sanitize an array of attributes into an attribute string. They can then be added to a script tag.

Check out the dev note for additional information and examples of use.

Standardized WP-Admin Colors

As part of a larger project aiming to clean up WP-Admin CSS, WordPress now uses a new standardized WP-Admin color palette. The new color palette includes 12 shades each of blues, greens, reds, and yellows. It also adds 13 shades of grays, blacks, and whites. Plus, it meets the minimum WCAG 2.0 recommended contrast ratio requirements.

In the words of Jean-Baptiste Audras:

Standardizing on this set of colors will help contributors make consistent, accessible design decisions. Themes and Plugin developers are encouraged to use this new color palette, for better consistency between their products and WordPress Core.

WP_MEMORY_LIMIT Constant in Site Health

The WP_MEMORY_LIMIT constant specifies the maximum amount of memory that PHP can consume.

Not included in previous WordPress versions as well, the WP_MEMORY_LIMIT constant has been added to the Info tab in Site Health.

Additional changes for developers are listed in Miscellaneous developer focused changes and REST API Changes in WordPress 5.7. You’ll find a full list of dev notes in the WordPress 5.7 Field Guide.

Summary

WordPress market share continues to grow at a steady pace:

WordPress is used by 64.4% of all the websites whose content management system we know. This is 40.3% of all websites.

It’s significant evidence of the CMS’s health, especially for those who build their business upon WordPress. And this is also an excellent reason to pay attention to what’s going on in the WordPress ecosystem.

WordPress 5.7 adds tons of new features and improvements for both users and developers, but that’s just a taste of what we may expect to see in 2021.

It’s up to you now. Did we miss anything important? What are your favorite changes and features of WordPress 5.7?