Block Locking Settings in WordPress 6.0

WordPress 6.0 makes it easier to lock blocks using the new controls modal. The release also includes two new settings to choose who can access this option and when.

BlockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. Editor

The new canLockBlocks setting can disable the feature globally or conditionally. Example:

add_filter(
	'block_editor_settings_all',
	function( $settings, $context ) {
		// Allow for the Editor role and above - https://wordpress.org/support/article/roles-and-capabilities/.
		$settings['canLockBlocks'] = current_user_can( 'delete_others_posts' );

		// Only enable for specific user(s).
		$user = wp_get_current_user();
		if ( in_array( $user->user_email, [ 'user@example.com' ], true ) ) {
			$settings['canLockBlocks'] = false;
		}

		// Disable for posts/pages.
		if ( $context->post && $context->post->post_type === 'page' ) {
			$settings['canLockBlocks'] = false;
		}

		return $settings;
	},
	10,
	2
);

Blocks

The lock property allows hide controls on a block type level. Example:

{
	"apiVersion": 2,
	"supports": {
		"lock": false
	}
}

For more info see #39183.

An earlier post on this blogblog (versus network, site) covers, the Curated experiences with locking APIs & theme.json

#6-0, #dev-notes, #dev-notes-6-0

Updates to the @wordpress/create-block templating system

A powerful feature of the @wordpress/create-block package is the ability to create templates to allow customization of how a blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. is structured.

WordPress 6.0 introduces some new template variables to allow even more customization. Templates can now use the customScripts variable to create new entries in the scripts property of the package.json file and while it was already possible to define dependencies, it is now also possible to defined a list of development dependencies using the npmDevDependencies variable. In addition to these new template variables, the @wordpres/env package will automatically be added to the list of devDependences when the template uses the wpEnv template variable or if the —wp-env flag is passed as a command line argument.

For more info see #38535#39723, and #38530.

#6-0, #dev-notes, #dev-notes-6-0

WordPress 6.0 Field Guide


Update on 5 May 2022: Updates to the @wordpress/create-block templating system and Block Locking Settings in WordPress 6.0 dev notesdev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include: a description of the change; the decision that led to this change a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. were added to the BlockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. Editor section.


With the Release Candidaterelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). 1 officially shipped, it’s time to explore the next major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope., WordPress 6.0. This release introduces Style variations, the Block Locking UIUI User interface, various writing improvements, more design tools, new hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same., updated external libraries, and more! At a high level, there are 97 enhancements and feature requests131 bug fixes and 13 Gutenberg bug fixes23 other blessed tasks, which brings us to 251 Trac tickets in total.

The new performance team has been working hard to improve various parts of WordPress. A lot of queries have been optimized and some removed, cache improved, multiple translations of the same strings removed, just to mention a few.

Let’s take a deeper look at what to expect in 6.0.

Note: Note: some of the changes will require pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-partyPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and theme authors to adapt or change their code. Please, read these Dev notesdev notedev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include: a description of the change; the decision that led to this change a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. Each important change in WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. is documented in a developers note, (usually called dev note). Good dev notes generally include: a description of the change; the decision that led to this change a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blogblog (versus network, site) during the betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field GuideField guide The field guide is a type of blogpost published on Make/Core during the release candidate phase of the WordPress release cycle. The field guide generally lists all the dev notes published during the beta cycle. This guide is linked in the about page of the corresponding version of WordPress, in the release post and in the HelpHub version page. at the beginning of the release candidate phase. carefully to make sure your code is ready for WordPress 6.0 on May 24, 2022.

Accessibility

Along with performance, lots of work has focused on improving accessibility in various parts of the WordPress software.

Block Editor

The Block Editor updates bring new functionality, fixes, and more:

  • The ability to bundle multiple Style variations for block themes.
  • The option to create page content patterns that users can choose from to create their pages.
  • New ancestor property in block.json letting one restrict where users can place their blocks.
  • A new block locking UI with a lock attribute for every block.
  • Registration of blocks from within themes.
  • Improved support for preserving unrecognized content in the editor.
  • More robust block theme export feature in the Site Editor.
  • Block markup updates for image, quote, list, and group blocks.
  • New set of Post Comments blocks, No Results block, and more.
  • & more!

Of note, if you currently have the Gutenberg plugin active on your website and are upgrading to WordPress 6.0, please make sure Gutenberg is updated to its latest version. This helps ensure the best experience possible.

Let’s dig in.

Bootstrap/Load

Amongst other performance improvements, in this release you’ll be able to skip not needed queries with do_parse_request filter.

Cache API

In WordPress 6.0 wp_cache_*_multiple API becomes a full CRUD. Also, option to flush the runtime cache without flushing the entire persistent cache is being enabled.

Media

Media has new filters and a few UI additions:

  • Enable edits to custom image sizes. Adds a filter edit_custom_thumbnail_sizes to allow users to enable editing individual custom image sizes. (#28277)
  •  Add a “Copy URL to clipboard” function to the list table view. (#54426)

We’ll find performance improvements in Media component as well.

Posts, Post types/Taxonomies

WordPress 6.0 introduces more dynamic hooks for custom post types and taxonomies.

Taxonomy

Taxonomies received a lot of performance improvements, from term query caching and adding limits to taxonomy queries, through navigation menu items to changing term_exists to use get_terms().

Themes

This new release offers a streamlined way for theme authors to work with patterns, support for multiple theme.json files AKA style variations, better export themes with Site Editor, and a few more goodies.

Allow block themes to be activated without index.php

This change removes the requirement for block themes to have an unused index.php template just for activation, as they use a templates/index.html file instead. (#54272)

Correct the logic for displaying a _doing_it_wrong() notice for add_theme_support( ‘html5’ )

  • Calling add_theme_support( 'html5' ) without passing an array of supported types should throw a _doing_it_wrong() notice: “You need to pass an array of types”.
  • If the second parameter is not specified, it should fall back to an array of comment-listcomment-form, and search-form for backward compatibility.
  • If the second parameter is not an array, the function should return false.

For more info see #51657.

Users

With 6.0 WordPress installs with more than 10,000 users, so called “large sites”, will receive performance improvements for querying and counting users.

Other Developer Updates

WordPress 6.0 also brings:

  • Option for plugin authors to edit plugin description on the Plugins > Add New and/or Network Admin > Plugins > Add New screens.
  • Ability to filter whole notification email in retrieve_password.
  • Possibility to remove site icons in multisite networks.

But Wait, There is More!

More than 131 bugs, 97 enhancements and feature requests, and 23 blessed tasks have been marked as fixed in WordPress 6.0.

Here are a few that haven’t been highlighted:

  • Administration: Add a media_date_column_time filter to the media list table date column. Similar to the existing post_date_column_time filter in the posts list table, this change adds a new hook to filter the “Date” column output in the media list view. (#42942)
  • Build: Update webpack to v5.x. This aligns closer with how the Gutenberg plugin handles WordPress packages. Enable React Fast Refresh support to WordPress core for block development with @wordpress/scripts. Bring caniuse-lite to the latest version which ensures that build tools target the most recent version of browsers supported by WordPress. (#51750, see #55505)
  • Build/Test Tools:
    • A .git-blame-ignore-revs file has been added to the repository with a curated list of “pinking shear” commits (ones only applying stylistic changes), making the blame feature on GitHub much more useful (#55422)
    • Webpack and all related build processes/scripts have been updated to version 5 (#51750).
    • The npm install command has been fixed for contributors using an Apple M series silicone by updating the grunt-contrib-qunit dev dependency (#52690).
  • Bundled Theme: If you’ve been having problems with order of elements in comment form in Twenty Nineteen theme, there’s a good news for you in #46600. It’s fixed!
  • Canonical: Function redirect_guess_404_permalink() includes all public statuses, rather than just publish, in 404 redirects in its search. (#47911)
  • Comments: Speeding up Dashboard and Comment moderation SQL load – (#19901)
  • Emoji: Update the Twemoji to version 14.0.2. This version introduces support for the latest Emoji added in Emoji 14. (#55395)
  • External Libraries:
  • Formatting:
    • Add support for formatting sizes as PB, EB, ZB, and YB. (#40875)
    • KSES: Add support for <ruby> and related elements. This is especially commonly used in Japanese content, but it can also been seen in content of other languages like Chinese. The set of elements to enable such functionality consists of <ruby><rt>, and <rp> in the HTML Standard, while some browsers (like Firefox) additionally support <rb> and <rtc> for more advanced formatting. (#54698)
    • KSES: Allow langxml:langdir attributes globally. Globally permit the langxml:lang, and dir attributes on all elements rather than a subset in accordance with the HTML specification. (#54699)
    • Function get_the_author_link() is going to be pluggable in WordPress 6.0. A new filter, get_the_author_link, is added for altering author link output. (#51859)
  • I18n:
    • List item separator should be a WP_Locale property (#39733)
    • Allow languages path in register_block_type (#54797)
  • Media:
    • Remove attachment_fields_to_save filter and deprecate image_attachment_fields_to_save(). This filter prevented removing attachment titles. This changeset removes the filter and deprecates the related function since it is no longer used. (#39108)
    • Enable edits to custom image sizes. With a new filter edit_custom_thumbnail_sizes users will be able to apply media edits to individual custom image sizes. (#28277)
  • Network/Sites: Improve cache key generation in WP_Site_Query (#55462)
  • Plugins:
    • Introduce the plugin_install_description filter. This allows for modification of the plugin card description on the Add Plugins screen. (#55480)
    • Convert apply_filters() into a proper variadic function. (#53218)
  • Posts, Post Types: Pass the $update parameter to wp_insert_post_data and wp_insert_attachment_data filters. This makes it easier to determine in a callback function whether this is an existing post being updated or not. (#46228)
  • Posts, Post Types; Taxonomy: Translate default labels once. Improve the translation of post type and taxonomy labels by caching the translations during runtime. (#26746)

Please, test your code. You can use the Beta Tester plugin on a test site to validate how your plugin or theme functions with WordPress 6.0 RC1.  Fixing issues that your code has with WordPress core helps you and millions of WordPress sites.

Props to @desrosj, @imath, @spacedmonkey, @swissspidy, @annezazu, @webcommsat, @jeffpaul, @costdev, @bph for contributing to this guide.

#6-0, #dev-notes-6-0, #field-guide

Miscellaneous Dev Notes for WordPress 6.0

Here are notes to a few further adjustments coming to WordPress 6.0 for developers.

Upgrade/Install

Replace a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party description on the Plugins > Add New Screen

The patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. #55480 introduces the plugin_install_description filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. in the WP_Plugins_Install_List_Table.

This new filter allows developers to modify or replace the description of a plugin on the Plugins > Add New and/or Networknetwork (versus site, blog) Adminadmin (and super admin) > Plugins > Add New screens.

The following example shows how to replace the description of specific plugin:

</p>
function wporg_plugin_install_description( $description, $plugin_data ) {
	if ( 'my-plugin' === $plugin_data['slug'] ) {
		$description = esc_html__( 'A new description for My Plugin', 'textdomain' );
	}

	return $description;
}
add_filter( 'plugin_install_description', 'wporg_plugin_install_description', 10, 2 );
<p>

For more info see #55480.

Users

Add ability to filter whole notification email in retrieve_password

New WordPress release introduces two new hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. to help developers to filter retrieve password emails:

  • send_retrieve_password_email can be used to filter whether to send the retrieve password email;
  • retrieve_password_notification_email can be used to filter the contents of the reset password notification email sent to the user.

For consistency with some similar filters like send_password_change_email or send_email_change_email, and for more flexibility, pass $user_login and $user_data parameters directly to the new send_retrieve_password_email and retrieve_password_notification_email filters.

apply_filters( 'send_retrieve_password_email', true, $user_login, $user_data );
apply_filters( 'retrieve_password_notification_email', $defaults, $key, $user_login, $user_data );

For more info see #54690.

Toolbar

Site icons in the toolbar My Sites menu

In large multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site networks, the site icons added to the toolbar navigation in WordPress 5.8 could make pages load significantly slower. To remove these icons, use the wp_admin_bar_show_site_icons filter.

add_filter( 'wp_admin_bar_show_site_icons', '__return_false' );

Without using the filter, these icons now include lazy loading when it is enabled for images. The loading attribute can be removed if it does not fit a site specifically in this context.

</p>
function wporg_disable_toolbar_image_lazy_loading( $default, $tag_name, $context ) {
    if ( 'img' === $tag_name && 'site_icon_in_toolbar' === $context ) {
        return false;
    }
    return $default;
}
add_filter( 'wp_lazy_loading_enabled', 'wporg_disable_toolbar_image_lazy_loading', 10, 3 );
<p>

For more info see #54447.

#6-0, #dev-notes, #dev-notes-6-0

Block Editor miscellaneous Dev Notes for WordPress 6.0

Updated 2022-05-07 with a table of content, two more dev notesdev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include: a description of the change; the decision that led to this change a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. and some formatting –bph

Table of Contents


Removed bottom margin on LineHeightControl component

Several UIUI User interface components currently ship with styles that give them bottom margins. This can make it hard to use them in arbitrary layouts, where you want different amounts of gap or margin between components.

To better suit modern layout needs, we will gradually deprecate these bottom margins. A deprecation will begin with an opt-in period where you can choose to apply the new margin-free styles on a given component instance. Eventually in a future version, the margins will be completely removed.

In WordPress 6.0, the bottom margin on the LineHeightControl component has been deprecated. To start opting into the new margin-free styles, set the __nextHasNoMarginBottom prop to true:

<LineHeightControl
  value={ lineHeight }
  onChange={ onChange }
  __nextHasNoMarginBottom={ true }
/>

For more info see #37160.

Props to @0mirka00 for writing this dev notedev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include: a description of the change; the decision that led to this change a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase.. (top)

Unrecognized blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. preservation

We’ve started making strides in preserving unrecognized content in the editor, also called (sometimes incorrectly) “invalidinvalid A resolution on the bug tracker (and generally common in software development, sometimes also notabug) that indicates the ticket is not a bug, is a support request, or is generally invalid.” or “missing.” In situations where the editor is unable to validate a loaded block against its implementation we run into numerous cases where content has previously been lost or corrupted, notably when inner blocks are involved.

Currently, we’re on the journey to preserving that original unrecognized content but have many corners in the project to update before it’s finished. Notably, when loading posts in the editor or in the code view that content will be preserved as it was loaded. Surprisingly, this lets us do something we’ve never been able to do before: intentionally create certain kinds of broken blocks within the code editor, or modify and fix blocks in the code editor whose block implementation is missing.

Still on the list to update are smaller parts of the flow such as the array of confusing block resolution dialogs and operations as well as certain validation steps that currently fail but shouldn’t.

In short, if you’ve been frustrated by the editor breaking your posts as soon as you hit “save” then good news is coming in 6.0.

For more info see #38794, #38923, and #39523.

Props to @dmsnell for writing this dev note.(top)

Registration of Blocks from within Themes

Until WordPress 6.0, building blocks inside plugins was the only way possible if you wanted to use block.json. This remains to be the recommended way to build Custom blocks  going forward. Blocks add functionality and therefore should be built as plugins that stay active even when a new theme is enabled. 

There are however instances where the styling and functionality of a block is so tightly coupled with a theme that it doesn’t make sense to have a block active without a given theme. This is true when building custom solutions, and the blocks are site-specific and not used for other instances. Furthermore, from discussion with agency project managers and developers, it turns out that there are considerable deployment costs when separating comprehensive solutions.

Each implementation had to reinvent a way to register blocks within themes, as WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. wouldn’t allow for it. With 6.0 the registration of blocks using block.json from within a theme is now technically standardized. You can use the same register_block_type function as you would inside a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and all the assets that you may register in the block.json file like the editorScript, style, etc get enqueued correctly.

For more info see #55513.

Props to @fabiankaegy for writing this dev note.(top)

Comments blocks – Enable legacy Post Comments block

With WordPress 6.0, there is a new set of blocks to show the Comments of a post:

  • Comments Query Loop: An advanced block that displays post comments and allows for various layouts and configurations.
    • Comment Template: Contains the block elements used to display a comment, such as the title, date, author, avatarAvatar An avatar is an image or illustration that specifically refers to a character that represents an online user. It’s usually a square box that appears next to the user’s name. and more.
    • Comments Pagination: Displays next/previous links to paginated comments where this has been enabled in the comment settings in the WordPress adminadmin (and super admin)
      • Previous Page: Displays the link to the previous page of comments.
      • Page Numbers: Displays a list of page numbers for comments pagination.
      • Next Page: Displays the link to the next page of comments.

The legacy Post Comments block, which directly renders the comments.php file, has been deprecated and hidden. It will still work for themes currently using it, but it won’t appear in the inserter.

The new set of blocks provides almost the same functionalities with the benefit that the layout and styles can be customized from the Editor. However, if any user wants to re-enable the Post Comments legacy block, they can use the block registration filters and adapt it to their needs. For example, this piece of code shows the legacy block in the inserter again and removes the “deprecated” from the title:

function wporg_enable_post_comments_legacy_block( $metadata ) {
    if ( 'core/post-comments' === $metadata['name'] ) {
        $metadata['title'] = esc_html__( 'Post Comments', 'textdomain' );
	$metadata['supports']['inserter'] = true;
    }
    return $metadata;
}
add_filter( 'block_type_metadata', 'wporg_enable_post_comments_legacy_block' );

For more info see #34994.

Props to @SantosGuillamot and @annezazu for writing this dev note.(top)

In order to implement this the spacing of the Gallery images had to be changed from a right margin setting to the CSSCSS Cascading Style Sheets. gap property. Themes or plugins that use a right margin setting to manually adjust the Gallery image spacing may need to be updated to instead override the gap setting.

Default gap changed

The new block editor block gap support functionality has been used to implement this and this adds a default block gap of 0.5em. For some themes that don’t explicitly set this gap, the default will change from the previous 16px to 0.5em. If plugin or theme developers want to ensure that the 16px gap remains the following CSS can be added to the theme, or site custom CSS:

.wp-block-gallery {
	--wp--style--gallery-gap-default: 16px;
}

Gallery Image bottom margins removed

Some themes may have depended on the bottom margin set on the gallery images to provide a gap between two galleries. Because the gallery now uses the flex gap for spacing this bottom margin is no longer set. Themes that were relying on this unintended side effect of the image margins will need to add the following CSS in order to maintain a gap between galleries:

.wp-block-gallery {
	margin-top: 16px;
}

Gallery gutter CSS var deprecated

To keep the naming of the gap setting consistent the --gallery-block--gutter-size CSS var has been deprecated and replaced with --wp--style--gallery-gap-default--gallery-block--gutter-size will continue to work in release 6.0 and will be removed in 6.1.

Theme authors should be able to provide compatibility for WP 5.9 and 6.0+ with the following:

.wp-block-gallery {
        --gallery-block--gutter-size: var( --wp--custom--spacing--4 );
	--wp--style--gallery-gap-default: var( --wp--custom--spacing--4 );
}

For more info see #40008.

Props to @glendaviesnz for writing this dev note.(top)

New ancestor property in block.json

Block developers sometimes need to restrict where users can place their blocks. For that, developers already count on APIs like block.json‘s parent property or the allowedBlocks option of the useInnerBlocksProps hook that allowed developers to express some basic, direct parent-children relations between blocks.

Since WordPress 6.0, the ancestor property makes a block available inside the specified block types at any position of the ancestor block subtree. That allows, for example, to place a ‘Comment Content’ block inside a ‘Column’ block, as long as ‘Column’ is somewhere within a ‘Comment Template’ block. In comparison to the parent property, blocks that specify their ancestor can be placed anywhere in the subtree, while blocks with a specified parent need to be direct children.

This property admits an array of block types in string format, making the block require at least one of the types to be present as an ancestor.

{
    "$schema": "https://schemas.wp.org/trunk/block.json",
    "apiVersion": 2,
    "name": "core/comment-content",
    "ancestor": [ "core/comment-template" ],
    ...
}

Block developers can also combine parent with ancestor inside block.json and use them together to express more complex relations if needed. For example:

  • Parent [ 'A' ] and ancestor [ 'C' ] would work as ”parent A and ancestor C”.
  • Parent [ 'A', 'B' ] and ancestor [ 'C', 'D' ] would work as ”parent (A or B) and ancestor (C or D)”.

Note that there are some edge cases uncovered by this APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways., like blocks that would require two or more different ancestor types simultaneously.

For more info see #39894.

Props to @darerodz for writing this dev note. (top)

Changes to media object returned from the WordPress data module

A small change has been made to the way the media objects are retrieved using the data module. The “caption”, “title” and “description” properties are returned as strings when using the `wp.data.select(‘core’).getRawEntityRecord` selector or the `wp.coreData.useEntityProp` hook.

Before

const [ renderedTitle ] = useEntityProp( 'root', 'media', id )?.rendered;

After

const [ renderedTitle ] = useEntityProp( 'root', 'media', id );

Props to @youknowriad for writing the note.

Removed Deprecated APIs

Some low-impact APIs that were deprecated on WordPress 5.4 have now been removed:

  • getReferenceByDistinctEdits selector.
  • PreserveScrollInReorder component.
  • dropZoneUIOnly prop in the MediaPlaceholder component.
  • isDismissable prop in the Modal component.
  • wp.data.plugins.control data module.

You can find more details on the #38564 removing these APIs

Slated to be removed in WordPress 6.2

The APIs listed have been deprecated in WordPress 5.3 and were forwarded in the background to the new ones already. They will be entirely removed in WordPress 6.2.

Old New
wp.editor.+[name] wp.blockEditor.+[name]
wp.data.dispatch( 'core/editor' ).+ name wp.data.dispatch( 'core/block-editor' ). + name
wp.data.select( 'core/editor' ).+ name wp.data.select( 'core/block-editor' ). + name
wp.components.ServerSideRender wp.serverSideRender

More details and discussion on PR #37854

Props to @youknowriad for writing the note.(top)

#6-0, #dev-notes, #dev-notes-6-0

Page creation patterns in WordPress 6.0

When a user creates a page, the editor starts with an empty canvas. However, that experience may not be ideal, especially since there are often possible patterns the user can use when creating a page, e.g., an about page, a contact page, a team page, etc.

Starting with WordPress 6.0, offering a set of patterns that users can choose from to create their pages is possible. We added a modal that shows possible patterns that can be used on page creation:

The modal appears each time the user creates a new page when there are patterns on their website that declare support for the core/post-content blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. types. By default, WordPress 6.0 CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. does not include any of these patterns, so the modal will not appear without some of these post content patterns being added.

Any theme or pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party can register a pattern with core/post-content block support and make the modal with the patterns appear. Here we provide a sample pattern that appears in this model.

register_block_pattern(
	'my-plugin/about-page',
	array(
		'title'      => __( 'About page', 'my-plugin' ),
		'blockTypes' => array( 'core/post-content' ),
		'content'    => '<!-- wp:paragraph {"backgroundColor":"black","textColor":"white"} -->
		<p class="has-white-color has-black-background-color has-text-color has-background">Write you about page here, feel free to use any block</p>
		<!-- /wp:paragraph -->',
	)
);

To register the page patterns via the theme.jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. file added the Body Types section to the php stub:

<?php
 /**
  * Title: Hello
  * Slug: my-theme/hello
  * Block Types: core/post-content
  * Categories: featured, text
  */
?>
<!-- wp:heading -->
  <h2>Hello</h2>
<!-- /wp:heading -->

More details on the auto-detection of patterns via .php files, are available in this Dev Notedev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include: a description of the change; the decision that led to this change a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase.: New features for working with patterns and themes in WordPress 6.0

Completely disabling this functionality

By default, no modal appears because there are no post-content patterns unless a theme or plugin registers one.
If one wants to disable the modal even if there are plugins registering post-content patterns, it is possible to do so by removing the post-content block type from all patterns, as the following code sample does:

$patterns = WP_Block_Patterns_Registry::get_instance()->get_all_registered();
foreach ( $patterns as $pattern ) {
	if (
		! empty($pattern['blockTypes'] ) &&
		in_array('core/post-content', $pattern['blockTypes'] )
	) {
		unregister_block_pattern( $pattern['name'] );
		$pattern['blockTypes'] = array_diff( $pattern['blockTypes'], array( 'core/post-content' ) );
		register_block_pattern( $pattern['name'], $pattern );
	}
}

For more info see #40034.

#6-0, #dev-notes, #dev-notes-6-0

Global Styles variations in WordPress 6.0

Theme authors can now create multiple theme.jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. variations and place them into their theme’s /styles folder. From there, users can switch between the various presets to something that suits them best.

Custom JSON files should follow the standard theme.json schema and their filename is going to be used as the variation’s label in the UIUI User interface (example blue.json).

Webfonts handler

A webfonts handler has been included in this release, allowing theme authors to include multiple font options within a single theme.json file or to offer vastly different styles by utilizing different font options in their multiple theme.json variations.

{
  "settings": {
      "typography": {
          "fontFamilies": []
      }
  }
}

Here’s a more robust example of how to implement this new option:

{
	"settings": {
		"typography": {
			"fontFamilies": [
				{
					"fontFamily": "-apple-system,BlinkMacSystemFont,\"Segoe UI\",Roboto,Oxygen-Sans,Ubuntu,Cantarell,\"Helvetica Neue\",sans-serif",
					"name": "System Font",
					"slug": "system-font"
				},
				{
					"fontFamily": "\"Source Serif Pero\", serif",
					"name": "Source Serif Pero",
					"slug": "source-serif-pero",
					"fontFace": [
						{
							"fontFamily": "Source Serif Pero",
							"fontWeight": "200 900",
							"fontStyle": "normal",
							"fontStretch": "normal",
							"src": [ "file:./assets/fonts/SourceSerif4Variable-Roman.ttf.woff2" ]
						},
						{
							"fontFamily": "Source Serif Pero",
							"fontWeight": "200 900",
							"fontStyle": "italic",
							"fontStretch": "normal",
							"src": [ "file:./assets/fonts/SourceSerif4Variable-Italic.ttf.woff2" ]
						}
					]
				}
			]
		}
	}
}

Right now, there is only support for top level settings and the more granular option of defining fonts per blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. is not currently available. For further inspiration, theme authors can review the approach the default Twenty Twenty-Two theme has taken since it will ship with three style variations with different fonts for WordPress 6.0.

Notes

  1. The variations require using the version 2 of theme.json.
  2. Right now when a variation is applied its contents are still merged with the theme and core theme.json, but it’s not possible to override a single value in an array of items or merge arrays. For example adding a value in settings.color.palette would replace the entire palette.

For more info see #38124.

Props to @annezazu for collaborating on this note.

#6-0, #dev-notes, #dev-notes-6-0

Separator block: Updated to use block supports color settings

To allow the setting of a custom opacity for each blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience., the Separator block has been updated to use the block that supports color settings. The custom opacity can then be set using the alpha channel setting of the selected color.

The HMTL structure of the block is unchanged, and all the existing classes are still in place, and two additional classes have been added – .has-alpha-channel-opacity and .has-css-opacity

These new classes have been added to maintain the default 0.4 opacity for all existing blocks in both the editor and the frontend. The opacity for existing Separator blocks will only change if the block itself has its color setting changed. If theme authors have opted in to block styles with add_theme_support( 'wp-block-styles' ); and wish to maintain the default 0.4 opacity setting for both new and old blocks the following CSSCSS Cascading Style Sheets. can be added:

hr.wp-block-separator.has-alpha-channel-opacity {
	opacity: 0.4;
}

#6-0, #dev-notes, #dev-notes-6-0

Block markup updates for image, quote, list and group blocks

Image blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. alignments

Historically, the image block with left, right or center alignments used to have an extra div wrapper around the figure tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) to help with alignment styling.

<div class="wp-block-image alignleft"><figure><img src="someimage.jpg" alt="" width="100" height="100"/></figure></div>

In WordPress 6.0, for themes that support the layout feature, this wrapper has been removed. The markup becomes:

<figure class="wp-block-image alignleft"><img src="someimage.jpg" alt="" width="100" height="100"/></figure>

The new markup/behavior for alignment classes is consistent regardless of the block and regardless of the chosen alignment.

To minimize the impact of this change on the websites, this change is only effective for themes with a theme.jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. file. These themes do support the “layout” feature which automatically provides the right styles for this new markup.

Quotes and lists

The blockquote, ul and ol tag names all now come with a default value for `box-sizing` equal to `border-box`. This change has been made as a bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fix for quote and list blocks using background colors or padding.

Group block stack variation

The new Stack block is a variation of the Group block, and can be thought of as a vertical variant of the Row block. It’s a flex container, meaning it has access to content justifications and block spacing. If combined with the Row block and its ability to optionally wrap onto new lines, it can enable basic responsive behaviors, such as two columns that stack to a single column on smaller displays.

Removal of data-align div wrappers

In the editor and to support/style block alignments, the editor used to add wrapper divs to any block that had an alignment applied to it.
For themes that support the layout feature (with theme.json file), the div wrapper with the `data-align` attribute has been removed. The markup now matches exactly the frontend output.

#6-0, #dev-notes, #dev-notes-6-0

Support for handling resolution errors for Editor data module

WordPress 6.0 no longer ignores the exceptions thrown by the resolvers.

In WordPress 5.9 and earlier, an exception thrown inside the resolver kept it in the resolving state forever. It never got marked as finished. In WordPress 6.0, the resolver state is set to error and the exception is re-thrown. This backwards compatibility-breaking change affects both resolvers from newly registered stores and the resolvers from the WordPress stores, e.g. the getEntityRecord resolver from the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. store.

Example:

Let’s register an example store where the resolver always throws an error:

const temperatureStore = wp.data.createReduxStore( 'my-store', {
    selectors: {
        getTemperature: ( state ) => state.temperature
    },
    resolvers: {
        getTemperature: () => { throw new Error( 'Network error' ); }
    },
    reducer: () => ({}), // Bogus reducer for the example
} );
wp.data.registerStore( temperatureStore );

Using that resolver has different results in different WordPress versions:

In WordPress 5.9:

const promise = wp.data.resolveSelect( temperatureStore ).getTemperature();

Error handling is unsupported, so this promise never gets rejected nor resolved.

In WordPress 6.0:

const promise = wp.data.resolveSelect( temperatureStore ).getTemperature();

Error handling is now supported, so this promise gets rejected with Error( ‘Networknetwork (versus site, blog) error’ )

The error details may be retrieved using the hasLastResolutionFailed, getLastResolutionFailure, and `getResolutionState` metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress.-selectors available on every registered store:

wp.data.select( temperatureStore ).hasResolutionFailed( 'getTemperature' );
// the above returns: true

wp.data.select( temperatureStore ).getResolutionError( 'getTemperature' );
// the above returns: Error( 'Network error' )

wp.data.select( temperatureStore ).getResolutionState( 'getTemperature' );
// the above returns: { "state": "error", "error": Error( 'Network error' ) }

The state returned by getResolutionState is one of: “resolving”, “finished”, “error”, undefined. The undefined indicates that the resolver hasn’t been triggered yet.

PRs #38669 #39317

#6-0, #dev-notes, #dev-notes-6-0