What’s new in WordPress 6.8: security upgrades, performance gains, editor enhancements, and more!

WordPress 6.8 is set for release on April 15, 2025. The next release does not introduce many new features; rather, it mostly focuses on refining existing functionality.

The new version brings editor and usability enhancements, with additions such as easier options for managing data views within the block editor and the ability to ignore sticky posts in the Query Loop, design and themes improvements, such as a revamped Style Book, performance and security improvements, with the introduction of Speculative loading and bcrypt for password hashing.

These additions aim to polish the user experience, particularly for those who use classic themes, and improve site performance.

Here is what you will find when you install WordPress 6.8.

Editor improvements

WordPress 6.8 brings several updates that enhance content creation and management experience. From new preview options to improvements in Data Views, these updates should streamline workflows in both the Post and the Site Editor.

1. Show template toggle in preview dropdown

A new Show template toggle has been added to the preview dropdown in the Post Editor’s top toolbar.

Previously, you could only access the Template options in the post sidebar. While this is a duplication, it is a noteworthy improvement, as placing this option in the toolbar dropdown makes switching between content and template views more straightforward and faster.

2. Improved Data Views

First introduced with WordPress 6.5, Data Views are a powerful tool in the Site Editor that allows users to view and manage pages, templates, template parts, and patterns in an organized way.

With WordPress 6.8, Data Views continue to evolve to provide a more intuitive, flexible, and efficient editing experience in the Site Editor. The focus is on improving usability and adding customization options.

The page view can be customized with more properties, including Preview, Slug, Parent, Discussion, Template, and Password. Preview is also available for Patterns and Templates.

WordPress 6.8 also introduces a new density control for the table layout, allowing users to adjust the space occupied by each row. With three options — Comfortable, Balanced, and Compact — users can customize the display to their preferences, making the management experience more versatile.

New and improved blocks

WordPress 6.8 introduces a brand new block and several updates to existing blocks.

1. A new Query Total block

The new Query Total block displays query-related information, such as the total number of results of a query or the range of results currently displayed.

You can add the new block within a Query Loop to display the number of results or ranges in paginated results.

2. Updates to the Query Loop block

Before WordPress 6.8, the Query block offered a limited number of options, including:

• Include – Sticky posts are prepended to the list of posts
• Exclude – Sticky posts are excluded completely
• Only – Only sticky posts are included

Missing from this set of options was the ability to ignore sticky posts by treating them as regular posts. This option was already supported by WP_Query (ignore_sticky_posts => true) but was not available as an option in the block sidebar.

WordPress 6.8 introduces an option to ignore sticky posts for “ignoring” the status of sticky. This means that developers and users can now prevent sticky posts from automatically appearing at the top of the result set, aligning their placement with the query’s inherent sorting logic.

This update enhances flexibility and consistency with WordPress’s core query behavior, making the Query block more versatile for content management in the block editor.

Another update to the Query Loop block replaces the Choose Pattern modal that appears when clicking on the Replace button in the block toolbar with a dropdown. The button now shows Change design.

3. Setting images as featured from the Image block toolbar

A new option allows you to set an image as featured from the block toolbar Options dropdown. If the post has a featured image already set, then the user can change it from the block toolbar as well.

4. Updates to the Navigation block

Several minor enhancements to the Navigation block improve its usability and overall functionality.

• The Navigation block now displays the menu name alongside the Navigation text (PR #68466).
• A Clear option is now available in the color picker for the Navigation block (PR #68454)
• All non-interactive formats are allowed within the Navigation link and submenu blocks (PR #67585)

For a more comprehensive list of improvements to the Navigation block in WordPress 6.8, check this dev note.

Design and themes improvements

WordPress 6.8 introduces significant enhancements to the site editing experience. The Global Styles interface has been revamped for easier access and real-time customization. At the same time, the Style Book extends its functionality to classic themes, bridging the gap between modern and traditional WordPress workflows.

1. Global Styles available on the site editor sidebar

With 6.8, the Global Styles interface is now accessible from the main menu of the site editor. Clicking on the Styles menu item brings up the Global Styles panel with all the Typography, Colors, Background, Shadows, and Layout options.

Clicking on the eye icon displays the Style Book, which shows the changes in the style settings in real time. When you click on a specific section of the Global Styles panel, you will be promptly directed to the corresponding section of the Style Book.

This change should make it easier and faster to customize your site styles, significantly improving the design workflows.

To make a difference, compare the Styles interface in WordPress 6.7 vs. 6.8.

WordPress 6.8 also brings this enhancement to classic themes.

2. Style Book added to Classic themes

Available for block themes since WordPress 6.2. With WordPress 6.8, the Style Book is also available for classic themes that support editor styles via add_theme_support( 'editor-styles' ) or have a theme.json file.

This feature was first introduced with Gutenberg 19.9. If you don’t use Gutenberg, starting with WordPress 6.8, you can access Global Styles and Style Book in classic themes from Appearance > Design > Styles.

The following images show the differences between the Styles section in WordPress 6.7 and the Style Book in WordPress 6.8 with Twenty Twenty-One theme installed.

Patterns have been moved to a separate section of the Design screen to make room for the Style Book in the Site Editor.

The following images show the previews of Typography and Colors in the Style Book of the classic Twenty Twenty-One theme in WordPress 6.8.

Introducing the Style Book for Classic Themes marks a step towards greater integration of block style editing features.

Performance and security

WordPress 6.8 brings significant improvements in performance and security. With the new Speculation Rules API, WordPress pages can load faster by predicting user actions. At the same time, switching to the bcrypt algorithm for password protection makes the system more secure against cyber attacks. Let’s dive in.

1. Speculative Loading in WordPress 6.8

Speculative loading is a website performance optimization technique that allows pages or resources to be prefetched or prerendered before the user accesses them, reducing load times and improving the user experience.

Speculative loading is based on the Speculation Rules API, an experimental API that allows developers to specify rules for prefetching or prerendering URLs based on expected user interactions through an interface defined in JSON.

The Speculation Rules API is currently supported by a limited number of browsers, mainly Chromium 121+-based browsers, such as newer versions of Chrome, Edge, and Opera.

Users of browsers that do not currently support the Speculation Rules API (Firefox and Safari) will not be penalized if a site uses speculative loading rules. They will simply not benefit from the performance improvements made possible by the API.

There are some important differences between prefetching and prerendering:

• Prefetching: prefetch rules within a <script type="speculationrules"> element or Speculation-Rules header forces the browser to download the response body of the specified pages, but without rendering those pages. Prefetching does not include loading subresources and executing JavaScript. The results are held in a specified cache, which is emptied when the user navigates away from the page. If the user leaves without having visited the prefetched pages, there is some waste of resources, but it is still less than with prerendering..
• Prerendering: prerender rules within a <script type="speculationrules"> element or Speculation-Rules header forces the browser to fetch, render, and load the content into an invisible tab, stored in a per-document in-memory cache. When you use prerendering, all subresources are loaded, and all the JavaScript code is executed. The results are kept in a dedicated cache emptied when the user leaves the page, except for the page the user navigates to. Prerendering brings considerable benefits in terms of performance but uses memory and network bandwidth and may cost a lot in terms of resources.

Speculation rules can be placed in an inline <script type="speculationrules"> element or in external files referenced by the Speculation-Rules HTTP header. Here is an example of usage in a script tag:

{
	"prefetch": [
		{
			"source": "list",
			"urls": ["firstpage.html", "secondpage.html"]
		}
	]
}

Before 6.8, WordPress users who wanted to add speculative loading to their WordPress websites could use the Speculative Loading plugin from the WordPress Performance Team. This plugin provides the performance benefits of the Speculation Rules API by automatically preloading or prerendering WordPress frontend URLs.

With 6.8, Speculative Loading enters the WordPress core with two new functions, a filter, and an action:

The new wp_get_speculation_rules_configuration() function returns the current speculation rules configuration (mode – prefetch/prerender – and eagerness – conservative/moderate/eager). Default values are prefetch and conservative to minimize resource consumption and prevent undesirable effects. According to the dev note, “it is in line with the configuration that Cloudflare uses in its speculative loading feature, and it minimizes the chance of any speculative loads without a subsequent navigation to the URL.”

The following code is an example of how to use the wp_get_speculation_rules_configuration() function that you can add in a plugin or the functions file of the active theme:

add_action( 'wp_footer', function() {
	$config = wp_get_speculation_rules_configuration();
	echo '<pre>';
	print_r( $config );
	echo '</pre>';
} );

The WordPress core implementation enables Speculative loading in the front end of all sites, except when a user is logged in or when permalinks are disabled.

We tested the speculative loading in WordPress 6.8, and we got the following output:

{
	"prefetch": [
		{
			"source": "document",
			"where": {
				"and": [
					{
						"href_matches": "//*"
					},
					{
						"not": {
							"href_matches": [
								"//wp-*.php",
								"//wp-admin//*",
								"//wp-content//uploads//*",
								"//wp-content//*",
								"//wp-content//plugins//*",
								"//wp-content//themes//twentytwentyfive//*",
								"//*//?(.+)"
							]
						}
					},
					{
						"not": {
							"selector_matches": "a[rel~=/"nofollow/"]"
						}
					},
					{
						"not": {
							"selector_matches": ".no-prefetch, .no-prefetch a"
						}
					}
				]
			},
			"eagerness": "conservative"
		}
	]
}

The wp_get_speculation_rules() function generates the entire JSON object of the Speculation rules based on the configuration.

You can use it as in the following example:

add_action( 'wp_footer', function() {

	if ( function_exists( 'wp_get_speculation_rules' ) ) {

		$rules = wp_get_speculation_rules();

		if ( ! empty( $rules ) ) {
			echo '<h4>Speculation rules:</h4>';
			echo '<pre>';
			echo esc_html( json_encode( $rules, JSON_PRETTY_PRINT ) );
			echo '</pre>';
		} else {
			echo '<p>Speculation rules are empty or invalid.</p>';
		}
	} else {
		echo '<p>wp_get_speculation_rules() not available.</p>';
	}
});

You can use the new wp_speculation_rules_configuration filter to change the default configuration, such as changing eagerness to moderate or eager or forcing a specific behavior.

You could use the wp_speculation_rules_configuration filter to prerender only related articles by adding a list of URLs with source = list instead of document, as in the following example:

add_filter('wp_speculation_rules_configuration', function( $config ) {
	$config['mode'] = 'prerender';
	$config['eagerness'] = 'eager';
	$config['urls'] = [
		'source' => 'list',
		'urls' => [
			home_url('/page-1/'),
			home_url('/page-2/')
		]
	];
	return $config;
}

The wp_load_speculation_rules action allows you to add custom rules in addition to the main core speculation rule, while the wp_speculation_rules_href_exclude_paths filter allows you to exclude additional paths from speculative loading.

According to the dev note, websites with speculative loading enabled improved their Largest Contentful Paint (LCP) by ~1.9% at the median. This is a notable result, considering this is the result of a single addition.

For an in-depth analysis of speculative loading, check out our in-depth tutorial. You can find full details on Speculative loading in WordPress 6.8 with usage examples in track ticket #62503 and the official dev note. See also Speculative Loading in WordPress by Felix Arntz.

2. Bcrypt for password hashing in WordPress 6.8

6.8 will change the algorithm used by WordPress to protect users’ passwords. WordPress currently uses phpass, which is not considered the best in terms of modern security. WordPress 6.8 switches to the more secure bcrypt encryption algorithm.

The main difference is that bcrypt takes more time and resources to crack, making cyber-attacks less effective.

In addition, application passwords, user password reset keys, personal data request keys, and the recovery mode key will switch from phpass to the more secure and faster BLAKE2b hashing algorithm.

No user action is required to implement this change:

When a user first subsequently logs in after the update – or when they next change their password – their password will automatically get rehashed with bcrypt and resaved in the database. Application passwords and security keys will not get automatically rehashed, but an existing hash will remain valid if it was generated before WordPress 6.8 and used before it expires.

Post passwords will continue using phpass for now, but this may change in the future.

For a closer view at the adoption of bcrypt with WordPress 6.8 and more in-depth analysis for developers, don’t miss the dev note from John Blackbourn.

Updates for developers

WordPress 6.8 also brings interesting updates for developers. These updates make creating and managing blocks easier, improving user interfaces and boosting website performance. Here’s a breakdown of what’s new and how it can help streamline development workflows.

1. Multiple block type registration in WordPress 6.8

WordPress 6.8 introduces a more efficient block type registration with the new function wp_register_block_types_from_metadata_collection(). This function allows developers to register multiple block types simultaneously, improving performance and streamlining block development.

It’s based on the block type registration APIs introduced with WordPress 6.7 and is particularly useful for plugins registering several block types with a single call, offering a more efficient and simpler approach to block registration compared to registering each block individually.

The main benefit is that you don’t need to call register_block_type() repeatedly for each block type you register with your plugin. You can now add a new block type to an existing plugin by simply creating a folder for that block type, and you don’t need to register the block type in the plugin’s PHP codebase because all block types are recognized and registered automatically.

To use this powerful feature, you need to create a manifest for all your block types. The manifest is a PHP file containing block metadata from all block.json files in the project, and you can generate it using the build-blocks-manifest command from the @wordpress/scripts NPM package.

Once you have generated your manifest, you can register all your block types with this single function call:

wp_register_block_types_from_metadata_collection(
	plugin_dir_path( __FILE__ ) . 'dist',
	plugin_dir_path( __FILE__ ) . 'dist/blocks-manifest.php'
);

For a closer view at the new wp_register_block_types_from_metadata_collection() function, check the dev note and the build-block-manifest command documentation.

2. Several updates to user-interface components in 6.8

WordPress 6.8 introduces several changes to user-interface components in the block editor, with several deprecations and updates. Some noticeable changes include:

• The Navigation component has been deprecated: The Navigation component (and all its subcomponents) are deprecated and planned for hard removal with WordPress 7.1. It will be replaced by the Navigator component.
• The Navigator component has been stabilized: The __experimentalNavigatorToParentButton and goToParent method from the __experimentalUseNavigator hook are deprecated, replaced by __experimentalNavigatorBackButton and goBack.
• The RadioGroup component has been deprecated: The RadioGroup component has been deprecated. You can use RadioControl or ToggleGroupControl instead.

For a comprehensive list of changes to user-interface components in 6.8, see the dev note.

3. Interactivity API updates

The Interactivity API gets several improvements. Before WordPress 6.8, when someone interacts with a page, all the related tasks happen at once, which can slow things down if they take longer than 50 milliseconds—something. To fix this, WordPress 6.8 introduces asynchronous handlers that allow to run these tasks asynchronously by default. This should help to improve INP (Interaction to Next Paint), which is an index that measures the responsiveness of a website to user interactions.

This change is being prepared for WordPress 6.8 but has not yet been fully implemented. Developers need to follow new best practices to avoid warnings and keep up with these improvements (like using asynchronous methods). The new features introduced are an intermediate step toward a faster and more reliable Interactivity API.

For a more in-depth drive through the new Interactivity API best practices, check the dev note by Felix Arntz.

4. A performance warning for developers

The useSelect hook helps fetch and manage data in the block editor, but if not used carefully, it can slow down a website.

Starting with WordPress 6.8, a new warning will appear in the developer console when SCRIPT_DEBUG is enabled if useSelect is called too often or inefficiently. More specifically, the warning displays if useSelect is triggered on every render (update) of a component without proper optimization.

The new warning should help developers identify possible performance bottlenecks. More details are in the dev note.

Summary

WordPress 6.8 focuses on refining existing features and improving performance. Key enhancements include improved editor usability, design upgrades with a revamped Global Styles interface, and Style Book support for classic themes. It also boosts performance with speculative loading via the Speculation Rules API while strengthening security with bcrypt password hashing.

But that’s not all. For a more comprehensive list of improvements and additions coming with WordPress 6.8, check the WordPress 6.8 Field Guide and other changes for developers on the official WordPress blog.

Now it’s your turn. Have you installed WordPress 6.8 yet? What are your first impressions? Feel free to share your thoughts in the comments section below.

The post What’s new in WordPress 6.8: security upgrades, performance gains, editor enhancements, and more! appeared first on Kinsta®.