What’s New in WordPress 6.1: Fluid Typography, Improved Template System, New Site Health Checks, and Much More!

WordPress 6.1 “Misha” has been released on November 1, 2022. The third major release of the year follows WordPress 6.0 Arturo, released on May 24, and WordPress 5.9 Josephine, released on January 25.

As it always happens, new WordPress releases bring new features, improvements, and bug fixes from the latest versions of the Gutenberg plugin into the core. And WordPress 6.1 is no exception, as 11 versions of the Gutenberg plugin have been merged into the core, from 13.1 to 14.1.

In this post, we will take a peek behind the curtains and introduce the new exciting features coming with the new major release of WordPress.

Matias Ventura gave us some insights in the Roadmap to 6.1, where he said that the goal of 6.1 is to refine the experiences introduced with 5.9 and 6.0 and fix some things as we approach phase 3 of the Gutenberg roadmap.

1. Template Editor Improvements: One of the main new features is the Template Editor. WordPress 6.1 should introduce the ability to browse, visualize, and edit the structure of the site.

2. Template Patterns: The goal is to give block patterns a central role in template and page creation, adapting them to custom post types and block types, enhancing locking functionality, improving saved pattern management, etc.

3. Global Styles and Blocks & Design Tools: WordPress 6.1 will allow managing webfonts, implement responsive typography, and expand the toolset available to blocks.

That said, let’s take a closer look at some of the most powerful features coming with WordPress 6.1.

Fluid Typography and Spacing

WordPress 6.1 adds support for Fluid Typography via calc/clamp CSS functions.

The expression Fluid typography describes the capacity of text to adapt to the viewport width, smoothly scaling from a minimum to maximum width.

It’s something different from what you can achieve with media queries, as media queries allow themes to resize text depending on specific viewport sizes but do nothing between different values.

Some themes already support fluid typography. Twenty Twenty-Two, for example, uses the CSS clamp() function for several font sizes. For example:

"settings": {
	...
	"custom": {
		"spacing": {
			"small": "max(1.25rem, 5vw)",
			"medium": "clamp(2rem, 8vw, calc(4 * var(--wp--style--block-gap)))",
			"large": "clamp(4rem, 10vw, 8rem)",
			"outer": "var(--wp--custom--spacing--small, 1.25rem)"
		},
		"typography": {
			"font-size": {
				"huge": "clamp(2.25rem, 4vw, 2.75rem)",
				"gigantic": "clamp(2.75rem, 6vw, 3.25rem)",
				"colossal": "clamp(3.25rem, 8vw, 6.25rem)"
			}
		}
	}
}

As you can see in the code above, fluid font size values are used for every single font size.

Now, starting with WordPress 6.1, themes are enabled to automatically generate fluid font sizes by declaring the new typography.fluid property as follows:

"settings": {
	....
	"typography": {
		"fluid": true,
		"fontSizes": [
			{
				"size": "2rem",
				"fluid": {
					"min": "2rem",
					"max": "2.5rem"
				},
				"slug": "medium",
				"name": "Medium"
			}
		]
}

Using typography.fluid and typography.fontSizes[].fluid, the value of every font size is automatically calculated using the following formula:

--wp--preset--font-size--{slug}: clamp({fluid.min}, {fluid.min} + ((1vw - 0.48rem) * 1.592), {fluid.max});

For example:

--wp--preset--font-size--large: clamp(2rem, 2rem + ((1vw - 0.48rem) * 1.592), {2.5rem});

Note that at the time of this writing, Fluid Typography is an experimental feature. You can dive into the technical details in Block supports: add fluid typography.

Fluid typography is a significant improvement for building modern #WordPress websites. We just updated @frostwp to include this feature. Here’s a great read from @richard_tabor into what it is and why it matters. https://t.co/Bq5YuHX3wi

— Brian Gardner (@bgardner) August 8, 2022

See also How to add Fluid Typography to WordPress Block Themes by Rich Tabor and Fluid typography with Gutenberg by Carolina Nymark.

Similarly to Fluid Typography, WordPress 6.1 also introduces support for Fluid Spacing.

Before WordPress 6.1, it was only possible to set custom spacing values in the editor, and theme authors were not allowed to specify fixed values for padding, margin, and gap. So, it was not possible to transfer spacing settings from one theme to another or to maintain spacing values when copying and pasting content between different websites.

Now theme developers can declare Fluid Spacing support using spacing.spacingScale and spacing.spacingSizes[] settings (see also Theme.json: Add spacing size presets and Extend theme.json to provide spacing size presets).

"settings": {
	"spacing": {
		"spacingScale": 
		{
			"steps": 0
		},
		"spacingSizes": [
			{
				"size": "clamp(1.5rem, 5vw, 2rem)",
				"slug": "30",
				"name": "1"
			},
			{
				"size": "clamp(1.8rem, 1.8rem + ((1vw - 0.48rem) * 2.885), 3rem)",
				"slug": "40",
				"name": "2"
			},
			{
				"size": "clamp(2.5rem, 8vw, 6.5rem)",
				"slug": "50",
				"name": "3"
			},
			{
				"size": "clamp(3.75rem, 10vw, 7rem)",
				"slug": "60",
				"name": "4"
			},
			{
				"size": "clamp(5rem, 5.25rem + ((1vw - 0.48rem) * 9.096), 8rem)",
				"slug": "70",
				"name": "5"
			},
			{
				"size": "clamp(7rem, 14vw, 11rem)",
				"slug": "80",
				"name": "6"
			}
		],
	...
	}
}

You’ll find fluid typography and spacing properties documented in Global Settings & Styles Presets and in the living reference to theme.json API V2.

Content-Only Block Editing

WordPress 6.1 introduces content-only editing for blocks, patterns, and templates. With content-only editing enabled, users can only change the content of a block or pattern, preventing them from accidentally breaking the layout or changing the styles.

Currently, it is not possible to enable content-only editing from the Visual editor interface. To enable this feature, the templateLock attribute should be set to contentOnly and you can use the Code editor for that.

The following image provides a simple example.

When content-only editing is enabled on a block or pattern, the settings sidebar changes. You won’t see the usual settings controls but a list of blocks included in the group. You can select any of those blocks by clicking on the block in the editor canvas or on the corresponding list item in the sidebar.

You can disable content-only editing by clicking the Modify button in the group toolbar.

Once you are finished with your edits, you can re-enable content-only editing by clicking the Done button.

In addition, blocks that have no content are hidden from the list view and cannot receive focus in the block list.

You can read more about content-only editing in the dev note and in this blog post by Rich Tabor.

Improved Block Types

With so many Gutenberg versions merged into the core, WordPress 6.1 is going to bring tons of changes and improvements to existing block types.

Added Border Support for the Columns block

The Columns block now leverages the new BorderBoxControl component that enables WordPress users to specify customized borders for columns, also setting completely different styles for each border (see also Column: Add border support to column blocks pull request).

Individual borders can also be set in the theme.json file as follows:

"core/column": {
	"border": {
		"top": {
			"color": "#CA2315",
			"style": "dashed",
			"width": "6px"
		},
		"right": {
			"color": "#FCB900",
			"style": "solid",
			"width": "6px"
		}
	}
}

Developers can read more about the new control in Component Reference – BorderBoxControl.

Border Controls for Image Blocks

Gutenberg 13.8 introduced support for all border controls for the Image block. The change will be added to the core with WordPress 6.1, opening the door for new and great opportunities for web creatives.

Comments Block Improvements

WordPress 6.1 also brings us an improved Comments Block. Starting with the next version of WordPress, users will be able to use more advanced editing features on the Comments block.

In the image below, you can see the Comments block settings sidebar and the changes applied to the Comments Title.

Post Terms Block Variations for Custom Taxonomy Terms

The Post Terms block has been enhanced with a new custom taxonomy variation. You can now register a new custom taxonomy, say “Actors in a Movie” post type, and you’ll be able to add a list of taxonomy terms to the current post or custom post type.

The image below shows a list of actors in a Movie post type.

A New Parents Filter for the Query Block

A new Parents filter is now available for the Query Block to display hierarchical posts and pages having the same parent.

Font Family Controls in the Heading Block

The Heading block now supports Font Family controls.

Horizontal and Vertical Spacing in Gallery Block

Starting with WordPress 6.1, a new axial spacing control allows you to set different horizontal and vertical gaps for images in the Gallery block.

This change results in greater flexibility when creating the layout of image galleries.

Featured Images in Cover Block

Featured images still get a lot of attention, and in WordPress 6.1, the scope of their usage is further extended. Starting with 6.1, the featured image can be selected directly from the Cover block placeholder, as shown in the following images.

This change should help to create a more consistent user experience making it clearer for the user what they are customizing.

Also, a Featured Image toggle has been added to media replace flow.

Appearance Tools for Post Navigation Links

The appearanceTools setting property allows you to opt-in to several settings that are disabled by default.

Since WordPress 6.1, for themes supporting the appearanceTools setting property, you can customize link color and font family in Post Navigation Link.

You can read more about the appearanceTools property in our introduction to the Twenty Twenty-Two theme.

Lock Inside Container Block With One Click

A new toggle now enables users to lock blocks in a container of blocks with a single click. This applies to Group, Cover, and Column blocks.

Enhanced List block

The List block has been enhanced and now leverages inner blocks.

This change makes it easier to sort and indent list items and definitely leads to an improved user experience.

Pseudo-elements Support in Block Themes

Now block themes can customize the appearance of elements and blocks depending on their state (active/focus/hover).

This is an example of using pseudo-selectors with links, as defined in Twenty Twenty-Three’s theme.json:

"styles": {
	...
	"elements": {
		"link": {
			"color": {
				"text": "var(--wp--preset--color--contrast)"
			},
			":hover": {
				"typography": {
					"textDecoration": "none"
				}
			},
			":focus": {
				"typography": {
					"textDecoration": "underline dashed"
				}
			},
			":active": {
				"color": {
					"text": "var(--wp--preset--color--secondary)"
				},
				"typography": {
					"textDecoration": "none"
				}
			},
			"typography": {
				"textDecoration": "underline"
			}
		}
	}
}

The following code button styles:

"styles": {
	...
	"elements": {
		"button": {
			"border": {
				"radius": "0"
			},
			"color": {
				"background": "var(--wp--preset--color--primary)",
				"text": "var(--wp--preset--color--contrast)"
			},
			":hover": {
				"color": {
					"background": "var(--wp--preset--color--contrast)",
					"text": "var(--wp--preset--color--base)"
				}
			},
			":focus": {
				"color": {
					"background": "var(--wp--preset--color--contrast)",
					"text": "var(--wp--preset--color--base)"
				}
			},
			":active": {
				"color": {
					"background": "var(--wp--preset--color--secondary)",
					"text": "var(--wp--preset--color--base)"
				}
			}
		}
	}
}

You can see the result in the following images.

But you can also style elements at a block level. The only difference is that you have to define styles within a block. As an example, the following code from Twenty Twenty-Three’s theme.json apply styles to links in the core Navigation block:

"styles": {
	"blocks": {
		"core/navigation": {
			"elements": {
				"link": {
					":hover": {
						"typography": {
							"textDecoration": "underline"
						}
					},
					":focus": {
						"typography": {
							"textDecoration": "underline dashed"
						}
					},
					":active": {
						"typography": {
							"textDecoration": "none"
						}
					},
					"typography": {
						"textDecoration": "none"
					}
				}
			},
			"typography": {
				"fontSize": "var(--wp--preset--font-size--small)"
			}
		}
	}
}

Additional Features and Improvements to The Block Editor

Although it is a consolidation version, WordPress 6.1 will bring so many changes and improvements that it would be impossible to list them all in one article (but check this article from Anne McCarty for a comprehensive list of per-block design tools).

Here, we’ll dive into the following changes:

Template Part Variations in the Block Inserter

Template part variations are now available in the block inserter, making it easier to add template parts to your website.

This change makes the editing process more straightforward and faster, allowing users to quickly view variations of a template part all at once with just a few clicks.

Visualize Margin and Padding

A small but useful improvement is the highlighting of the margins and padding while the user is adjusting them. This should make it much clearer how much space is being added inside or outside the elements.

Improvements to the Settings Sidebar

WordPress 6.1 will also showcase several interface improvements to the Settings sidebar.

The post settings sidebar has been slightly redesigned. Now the fields for post format, slug, template, and authors are aligned and have the same width. In addition, the post scheduler has been simplified to make the experience more understandable. The template section has also been moved into a popover to save space and clean up the interface.

In addition, the template panel has been replaced by a template link. When clicked, the template link displays Default template in a popover.

Publish Popover Design Updates

The datetime picker in the Publish popover has been redesigned and now uses “existing WordPress components and Emotion styling.”

More technical insights are available in Design updates to the Publish popover (DateTimePicker).

Time to Read in the Info Panel

The Information panel available in the top toolbar has been improved and now displays Time to read in addition to Words, Characters, Headings, Paragraphs, and Blocks.

The estimated reading time is calculated on an average of 189 words per minute. Read more in @wordpress/editor: Add estimated time to read to table of contents in editor.

Block Spacing Control Added to Styles UI

Now users can adjust vertical and horizontal spacing from the Styles UI for blocks supporting this feature.

New and Improved Building Tools

WordPress 6.1 will also extend the functionality of the Site Builder. Block Patterns will be available in more places and a wider choice of template types will improve the editing experience in the template editor.

Creation Patterns for Post Types

WordPress 6.0 introduced Page Creation Patterns, which are a way to provide a selection of patterns each time a user creates a new page. This way, you don’t have to build the page from scratch but can pick a pattern from a modal and fill in the content, and you are ready to go.

To enable this feature, at least one block pattern should declare support for the core/post-content block types.

Now, starting with WordPress 6.1, this feature extends to all post types. All you need to do is include core/post-content in your pattern’s blockTypes and set the relevant postTypes.

Now let’s find out how to take advantage of this new feature with a practical example. Assume that you have a Movie post type.

First, you need to register a block pattern as discussed here.

Or you can go the easy way and use the implicit pattern registration (for simplicity in this example, we’ll use implicit pattern registration).

Create a PHP file for your block pattern in a /patterns directory in your theme’s folder (for this example, we used Twenty Twenty-Two). Then add the following heading:

<?php
/**
 * Title: Pattern with columns
 * Slug: twentytwentytwo/pattern-with-columns
 * Block Types: core/post-content
 * Post Types: movie
 * Categories: text
 */
?>
<!-- wp:heading -->
<h2>Hello there!</h2>
<!-- /wp:heading -->

And that’s it. Now, each time you create a new Movie post type, a Choose a pattern modal appears on the screen.

If you want the modal to show up on multiple post types, just add the corresponding slugs separated by commas:

<?php
/**
 * Title: Pattern with columns
 * Slug: twentytwentytwo/pattern-with-columns
 * Block Types: core/post-content
 * Post Types: movie, book
 * Categories: text
 */
?>
<!-- wp:heading -->
<h2>Hello there!</h2>
<!-- /wp:heading -->

For a closer view of creation patterns, see Ability to use creation patterns for other post types besides page.

More Template Types in the Site Editor

With WordPress 6.0, only a limited number of templates can be created in the Site Editor:

Starting with WordPress 6.1, it will be possible to create a different template for each individual post type.

And you can also add and edit templates for core and custom taxonomies, even for single categories or tags.

If you register custom post types or a custom taxonomy, they will be automatically listed in the template selection box of the Site Editor.

But not only that. Once selected the template post type, a modal prompts the user whether to create a template for all posts of that type or to create a new template for a specific post of the selected post type.

Then a new modal provides a list of the posts available for that post type.

Twenty Twenty-Three and Other Theme Improvements

WordPress 6.1 also delivers a brand new default theme: Twenty Twenty-Three. It is a minimalist theme with no images or additional functionality.

The new default theme gathers all the latest site editing features in one place and is a perfect sandbox for testing templates and template parts, style variations, flexible typography and spacing, and all the features introduced with the latest versions of WordPress.

And because of that, it is also a great tool for learning how to develop themes, templates, and block patterns with working examples.

You can dive deeper into the new WordPress default theme in our in-depth overview.

Apart from the new default theme, WordPress 6.1 also introduces several theme improvements.

Update URI Header in Themes

Before WordPress 6.1, if a theme had the same name as a theme available in the WordPress themes directory, an available update message was shown to the user.

With WordPress 6.1, a new Update URI header prevents to accidentally overwrite third party theme files. This feature is particularly useful if you have an in-house developed theme with the same name as a theme in the WordPress Theme Directory but don’t want to share it with the community.

Now, if the value of Update URI theme header field doesn’t match https://wordpress.org/themes/{$slug}/ or w.org/theme/{$slug}, WordPress won’t attempt to update it.

If set, Update URI should be a URI with unique hostname, such as https://wordpress.org/themes/my-theme/ or https://example.com/my-theme/.

Theme developers will find a more in-depth overview of the new Update URI theme header in the official dev note.

Block Themes Filter Under “Add Themes” Screen

A new shortcut now allows to filter block themes when adding a new theme to your WordPress installation.

Also, a new Block Themes help tab has been added to the same screen.

Changes for Developers

WordPress 6.1 also adds a new API and many features and changes for developers.

New Preferences Persistence API

WordPress 6.1 introduces a brand new preferences persistence API that saves editor preferences in the WordPress database instead of local storage.

This way, user preferences can be stored across all browsers and devices.

For this purpose, the previous persistence system in the @wordpress/data package has been deprecated, and a new preferences-persistence package has been introduced. The new package saves data to user meta via the Rest API. The data will also be saved in the local storage as a fallback in case the user goes offline or a request is interrupted (see also pull #39795).

Support for Button Styles in theme.json

With WordPress 6.1, you can add button styles to your themes using theme.json. This allows theme developers to add consistency to buttons across blocks. An example is the search block, but also third-party blocks will benefit from this change.

To make it possible, a new wp-element-button class will be added to button elements to share the same style.

You can test this change by adding the following code to your theme.json in a development environment:

{
	"styles": {
		"elements": {
			"button": {
				"color": {
					"background": "blue"
				}
			}
		}
	}
}

Search Block Variations Now Support Query Vars

WordPress 6.1 will support Search block variations based on query vars. This means that you’ll be able to provide your users with search boxes to be used to granularly search for any type of content.

In the following example, we’re registering a block variation for a movies post type. The example is based on Carolina Nymar’s tutorial about Block variations.

In your (child) theme’s functions file, add the following code:

function movies_editor_assets() {
	wp_enqueue_script(
		'movies-block-variations',
		get_template_directory_uri() . '/assets/block-variations.js',
		array( 'wp-blocks' )
	);
}
add_action( 'enqueue_block_editor_assets', 'movies_editor_assets' );

Now, create the following block-variations.js file in your (child) theme’s assets folder:

wp.blocks.registerBlockVariation( 
	'core/search', 
	{
		name: 'movie-search',
		title: 'Movie Search Block',
		attributes: {
			query: {
				post_type: 'movies'
			}
		}
	} 
);

Now reload your WordPress dashboard and search for a Movie Search Block variation in the block inserter.

You can read more about block variations in the official documentation.

A New Buttons Element in Global Styles

WordPress 5.9 introduced a Global Styles interface to enable users to customize style presets for their websites, either globally or at block level.

With the first implementation, you could customize the colors for Background, Text, and Links. Now, starting with WordPress 6.1, a new Buttons element has been added to the Colors panel to enable users to control the appearance of buttons across their entire websites.

This would affect button style in everything across the site, from the Buttons block to the Search block and third-party blocks making use of buttons.

Appearance Tools Available for Any Theme

Before WordPress 6.1, Appearance Tools were only available in block themes. With 6.1 any theme can include this feature by simply adding support in their functions file:

add_theme_support( 'appearance-tools' );

This would enable all the following settings at once:

• border: color, radius, style, width
• color: link
• spacing: blockGap, margin, padding
• typography: lineHeight

New is_login_screen() Function

A new is_login_screen() function now allows you to determine if the current page is the login screen. Custom login locations are also supported.

You can use the new conditional tag as follows:

function add_text_to_login() {
	if ( is_login_screen() ) {
		echo( "<h1>Welcome to Kinsta!</h1>" );
	}
}
add_action( 'init', 'add_text_to_login' );

The result on the screen would be the following:

New Site Health Checks for Persistent Object Cache and Full Page Cache

WordPress 6.1 introduces two Site Health checks for Persistent Object Cache and Page Cache. Both checks only run on production environments.

You can view the results of these new tests in the Status tab of the Site Health screen.

The Persistent Object Cache test determines whether the site uses a persistent object cache and, if not, recommends using it if it makes sense for the site.

In addition to the new test, WordPress 6.1 introduces several new filters that hosting providers can use in their respective environments.

With site_status_persistent_object_cache_url hosts can replace the default Learn more link for persistent object cache with a custom link. For example:

add_filter( 'site_status_persistent_object_cache_url', function() {
	return 'https://example.com/persistent-object-cache';
} );

With site_status_persistent_object_cache_notes hosts can replace the default notes to recommend their preferred object caching solution. Here is an example of usage:

add_filter( 'site_status_persistent_object_cache_notes', function( $notes ) {
	$notes = __( 'Custom notes.', 'text-domain' );
	return $notes;
} );

site_status_persistent_object_cache_thresholds filters the thresholds used to determine whether to suggest the use of a persistent object cache. Default values are:

$thresholds = apply_filters(
	'site_status_persistent_object_cache_thresholds',
	array(
		'alloptions_count' => 500,
		'alloptions_bytes' => 100000,
		'comments_count'   => 1000,
		'options_count'    => 1000,
		'posts_count'      => 1000,
		'terms_count'      => 1000,
		'users_count'      => 1000,
	)
);

You can use the filter as follows:

add_filter( 'site_status_persistent_object_cache_thresholds', function( $thresholds ) {
	$thresholds = array(
		'alloptions_count' => 700,
		'alloptions_bytes' => 150000,
		'comments_count'   => 1500,
		'options_count'    => 1500,
		'posts_count'      => 2000,
		'terms_count'      => 1000,
		'users_count'      => 2000,
	);
	return $thresholds;
} );

site_status_should_suggest_persistent_object_cache is a short-circuit filter that filters whether to suggest use of a persistent object cache and bypass default threshold checks. You can use it as follows:

add_filter( 'site_status_should_suggest_persistent_object_cache', '__return_true' );

The Full Page Cache test checks whether the site is using full page cache and if the response time is OK:

Two new filters also enable hosts to customize the response threshold and add custom cache headers to be detected.

The site_status_good_response_time_threshold filters the threshold below which a response time is considered good. The default value is 600 ms (see also Slow server response times affect performance).

site_status_page_cache_supported_cache_headers enables hosting providers to add custom cache headers and the corresponding verification callbacks. The dev note provides the following example of usage:

add_filter( 'site_status_page_cache_supported_cache_headers', function( $cache_headers  ) {
	// Add new header to the existing list.
	$cache_headers['cf-cache-status'] = static function ( $header_value ) {
		return false !== strpos( strtolower( $header_value ), 'hit' );
	};
	return $cache_headers;
});

Developers can dive deeper into the new Site Health checks in:

• Proposal: Persistent Object Cache and Full Page Cache Site Health Checks
• New cache Site Health checks in WordPress 6.1
• Port Audit Full Page Cache from performance plugin to core
• class-wp-site-health.php

Create-block Scaffolding Tool Updates

WordPress 6.1 also introduces new features and updates to the @wordpress/create-block package available for developers to scaffold new blocks.

A block scaffolding is the supporting directory structure allowing WordPress to recognize a block.

A couple of new features and several improvements are introduced with WordPress 6.1.

A new –variant flag allows block developers to choose a block variant to be scaffolded. The internal templates provided by the create-block tool support dynamic and static variants, that means that you can scaffold a dynamic or static block respectively. Default is static.

You can use the new flag as follows:

npx @wordpress/create-block my-first-block -variant=dynamic

Developers can define custom variants by adding a variants object to the template definition.

An additional feature now enables block developers to add new blocks to an existing plugin thanks to the --no-plugin flag.

npx @wordpress/create-block custom-block --no-plugin

Running the command above creates a new set of block files in a subdirectory to the current directory.

Note that the script is not aware of its location:

Calling npx @wordpress/create-block block-name --no-plugin will create a new block inside the folderNamedirectory where it’s called

You can read more about create-block scaffolding tool updates.

Caching Query Results in WP_Query

WordPress 6.1 changes the way database queries are executed in the WP_Query class. As of 6.1, queries will be cached with the result that if a query is executed more than once, the results will be loaded from the cache.

Both sites using persistent object caching and sites using in-memory caching will benefit from this change, although the benefits for the latter will be smaller.

By default, all calls to WP_Query will be cached, but developers can opt out of caching queries using the cache_results parameter:

$args = array(
	'posts_per_page' => 20,
	'cache_results'  => false
);
$query = new WP_Query( $args );

You can also disable query caching globally using the disable_caching hook, although it is not recommended.

It is worth noting that some query parameters are not considered for query caching purposes. The most commonly used of these parameters is the fields parameter. The reason is that taking fields into account would have produced multiple caches for several subsets of the same data, thus leading to performance degradation.

For a deeper overview of WP_Query caching, see Improvements to WP_Query performance in 6.1 dev note.

Template Parts in Classic Themes

Starting in WordPress 6.1, classic themes support block-based template parts. To add this feature, themes need to add support for block-template-parts as shown below:

function add_block_template_part_support() {
	add_theme_support( 'block-template-parts' );
}
 
add_action( 'after_setup_theme', 'add_block_template_part_support' );

Classic themes can include template parts in PHP templates using the block_template_part function. You can read more about this feature in Block-based “template parts” in traditional themes dev note.

A Note About JPEG to WebP Image Conversion

Initially it seemed that WordPress 6.1 would have also introduced support for automatic JPEG to WebP image conversion.

However, many contributors reported several issues. Specifically, it was noted that:

Resources for generating images when you upload an image will increase dramatically, however resources to serve an image will be lowered. Since image uploading is very rare compared to image serving, the extra effort to compress and store images should be worth it.

And:

Actually that dramatic increase of resources usage when uploading an image is a very bad side effect here. It means a lot of uploads will fail, and leave the users stranded. It also will increase support requests for both WordPress and the hosting companies dramatically. Don’t think this is acceptable. Because of this, even if image multi-mime support is needed in WordPress, the current approach doesn’t seem like a good solution.

Finally, after a post by Matt Mullenweg on WordPress.org, JPEG to WEBP automatic conversion has been pulled out from WordPress 6.1.

I am interested in supporting new formats and improving performance, but I think this change being pushed by default to users when they upgrade to 6.1 is a lot for right now, including with some of the clunky interactions OSes still have around webp (and HEIC!) files.

I’m happy for support for working for webp and HEIC files to stay in core, as we should be liberal in what we accept and work with, but not with the change to convert everything to webp when JPEGs are uploaded.

This is excellent territory for a canonical plugin, a concept I think every Make team should be exploring a lot more as a place to experiment and push functionality…

Anyway, WordPress users and developers can test automatic JPEG to WebP image conversion by installing the Performance Lab plugin from the WordPress Performance Group.

Additional Changes for Developers

In addition to the features and improvements we discussed above, WordPress 6.1 introduces several additional changes for developers. You may want to dig deeper into these changes in the dev notes:

• Improved PHP performance for core blocks registration
• Navigation Block Fallback Behavior in WP 6.1
• Spacing Size Presets in theme.json
• Escaping Table and Field names with wpdb::prepare() in WordPress 6.1
• WP_List_Table::get_views_links() in WordPress 6.1
• Functions and hooks for required fields in WordPress 6.1
• Moving the send_headers action to later in the load
• Performance improvements to the REST API
• Editor Components updates in WordPress 6.1
• Multisite improvements in WordPress 6.1
• Miscellaneous Core changes for WordPress 6.1
• Performance Field Guide for WordPress 6.1
• Miscellaneous REST API improvements in WordPress 6.1
• Block API changes in WordPress 6.1
• Miscellaneous editor changes for WordPress 6.1
• Updated editor layout support in 6.1 after refactor
• Changes to block editor preferences in WordPress 6.1
• Block styles generation (Style Engine)
• Reference Styles values in theme.json

Summary

With WordPress 6.1 we are seeing the consolidation of WordPress site editing capabilities. We are still in phase two of the Gutenberg long-term roadmap, but the tools and features available to us are becoming more reliable and robust over time. WordPress 6.1 brings Fluid Typography, new site-building tools, and tons of improvements to existing blocks.

But not only that. WordPress 6.1 also brings significant improvements in CMS performance. Two new Site Health checks detect the use of Full Page Cache and Persistent Object Cache, query caching improves WP_Query performance and there are also improvements to PHP performance for core block registration.

In short, 6.1 is a version that WordPress users and designers will love, as well as developers, who will benefit from many improvements in several areas of the CMS.

Now up to you. What do you like most in WordPress 6.1? Have you already tested new version in your development environment? Share your thoughts on WordPress 6.1 with us in the comments section below.