What’s new for Navigation in WordPress 6.2 and 6.3

This post was co-authored by @scruffian.

Since the last update, contributors have added many new features to the Navigation 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. and also the wider navigation management system within WordPress.

These improvements are designed to help users manage their navigation menus and provide a more consistent and reliable experience.

Let’s take a look at what’s changed…

Navigation List View

One aspect of the navigation block is that parts of it are often hidden – for example submenus aren’t always open. This can make managing the items within a navigation block in the editor canvas challenging. 

For this reason, WordPress 6.2 added an editable “List View” component to the navigation block inspector controls which lays out the navigation structure with every item visible:

In addition to the standard block tools, the list view allows all the usual ways of managing navigation items. You can:

  • Add and remove navigation items.
  • Reorder navigation items.
  • Create new submenus.

Adding this feature to the block also prepared the groundwork to allow contributors to unlock several exciting new features in WordPress 6.3.

Navigation in Site View

With WordPress 6.3, it is now possible to manage your navigation from outside of the context of a Navigation block and without needing to edit a template. 

When in the Site Editor a new “Navigation” section is available within the Site View sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. which lists all of your navigation menus and allows you to manage them without having to find the templates (and blocks) they are used within:

One you click through to a Navigation you can:

  • Rename, duplicate and delete navigation.
  • Reorder items within a navigation.

Known limitation: currently you cannot add new items, but contributors are considering avenues to enable this for a future release.

One benefit of this view is that when multiple blocks all share the same navigation menuNavigation Menu A theme feature introduced with Version 3.0. WordPress includes an easy to use mechanism for giving various control options to get users to click from one place to another on a site., the user now has a single place to manage the menu items.

Focus Mode for Navigation

Surfacing navigation as a list within the Site View is excellent for simple use cases, but sometimes it’s useful to see the navigation within the editor canvas to better visualize the changes being made.

For this reason WordPress 6.3 sees the addition of “Focus Mode” for Navigation whereby the navigation menu is displayed within an editor canvas completely isolated from any surrounding site context.

You can access this new mode by clicking on the “Edit” button within the Navigation block’s toolbar, or by browsing to an individual navigation from the “Navigation” section of the Site View sidebar.

Focus mode provides full scope to modify the blocks that are inside the navigation block (the “menu items”), allowing you to add new items and even make use of the editable list view in the block’s  sidebar:

It is important to note that as a given navigation menu may be used across multiple block’s on a site – each of which will have their own place within the overall design of your site – the ability to change the visual representation of the Navigation block itself has been intentionally disabled. 

This allows you to focus soley on the contents of the navigation menu.

Another benefit of this feature is that it is now possible to access and edit the inner blocks of a navigation simply by switching the editor to “code view” mode:

Managing your navigation in isolation can be extremely useful, but sometimes it’s handy to see your navigation menu within the context of which it is being displayed. This is precisely what the next feature seeks to address.

Navigation in Patterns and Template Parts

Patterns and Template Parts often contain navigation block’s. The classic example of this is a “HeaderHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes.” template part containing a site logo block and a navigation block.

In WordPress 6.3, when editing a template part or a pattern that contains a navigation block, you will see any associated navigation menu displayed in the sidebar in an editable list view.

This gives you quick access to manage the navigation that is used in the canvas without needing to switch to editing the block directly within the canvas itself. 

Moreover, by displaying the name of the navigation in the sidebar, it is immediately apparent which navigation menu is being used by the block. In the future it may be possible to complement this in a reciprocal way when viewing a single Navigation Menu by listing the templates where the navigation is used.

Automatic creation of Navigation fallbacks

Previous versions of WordPress had the concept of a “fallback” Navigation which was utilized in scenarios where a Navigation block has no navigation menu associated with it. 

Depending on whether the site had existing Navigation Menus, the mechanism would either fetch an existing navigation or create a new one from scratch.

However the implementation provided a suboptimal user experience, with a noticeable loading delay upon block modification caused by fetching/creating the (“fallback”) navigation menu to be associated with the block.

With WordPress 6.3 however, this experience has been greatly improved with each Navigation block now being automatically assigned a navigation menu upon insertion. This means that once a block is ready, edits will not trigger further “loading” delays as changes are simply synchronized to the navigation menu already associated with the block.

Technical Implementation

This has been achieved by moving the majority of the fallback logic to the WordPress REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/.. A new dedicated “Navigation Fallback” endpoint now immediately returns the most “suitable” fallback navigation menu for your site.

What does “suitable” mean? This is much the same as for WordPress 6.2, namely when called the endpoint…

  • Returns the most recently created existing Navigation Menu.
  • (if not available then…) Returns a Navigation Menu created from the most recently created Classic Menu (note: this is a one time import, and changes to the original Classic Menu are not synced to the block-based Navigation Menu).
  • (if not available then…) Creates and returns a new Navigation Menu, typically comprising a list of the current site’s Pages.

This heuristic may evolve in future releases to allow the fallback to be sensitive to the context in which it is being displayed. For now however, the improvement to the block’s user experience and reliability is a welcome improvement over previous versions.

Opting out of automatic fallback creation

If you’d like to opt out of automatic creation of Navigation fallbacks you can use the wp_navigation_should_create_fallback hook as follows:

add_filter( 'wp_navigation_should_create_fallback', '__return_false' );

See the original PR for full details.

Other improvements

Performance

On top of the improvements to perceived performance delivered by improving the fallback navigation system, WordPress 6.3 also provides an additional enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. to the performance of the navigation system.

In #48683 contributors added the navigation endpoints to the list of endpoints that are preloaded in the editor. This means that when the editor loads the list of navigation menus will already be available to display and use within the block and/or Site View sidebar. 

This simple change makes it possible to access and manage your navigation, which is a key facet of most websites and makes for a greatly improved user experience.

Login/Logout

It is common for websites to provide a login and logout link for their users. In #49160  we added this block to the list of blocks that are allowed within the navigation block so that users can add this functionality to their navigation.

What do you think?

This concludes our brief overview of the key changes to the navigation system in WordPress. 

As always we are open to your feedback. What do you think? Are these improvements impactful for you? What is missing and what you would like to see? Your thoughts are appreciated in the comments below.

Bugs – we appreciate it if any bugs are reported on Github.

What’s next?

Of course, whilst there has been much progress contributors recognise that there is still much to do.

Our focus for future releases will be  updated on the relevant Tracking Issue and we encourage you all to take a look and let us know any feedback you might have on the proposals outlined there.

You can also join us on WP CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. (sign up required) in the #feature-website-navigation channel.

Props to @scruffian who co-authored this post and to @draganescu and @annezazu for review.

#6-3, #dev-notes, #dev-notes6-3, #navigation, #navigation-block

Miscellaneous developer changes in WordPress 6.3

Administration

Added the no-store and private directives to the Cache-Control headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. to prevent caching for logged in users. This prevents sensitive data on logged-in users from being cached and available to others, for example, via the browser history after the user logs out. (#21938)

External Libraries

jQuery has been updated from v3.6.4 to v3.7.0. (#58083)

The latest version of jQuery includes 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. fixes, a new method called .uniqueSort(), Sizzle selector engine, and a performance improvement for some use cases when using manipulation methods like .append().

The .uniqueSort() method is used to sort an array or an array-like object of DOM elements and remove any duplicate nodes.

Sizzle, its selector engine, has been included as inlined code and removed as a project dependency, along with the removal of some workarounds for legacy browsers in the process.

References:

Login and Registration

Adding required attributes to username and password input fields

In WordPress 6.3, the WordPress login form includes the required attributes for username and password fields, resolving ticketticket Created for both bug reports and feature development on the bug tracker. #32510. This change, while minor, may have some ramifications for 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 developers.

The change adds semantic clarity to explicitly mark these fields as required, reinforcing the implied expectation that has always been in place for login fields.

Impact for Developers

Plugins that bypass login fields or login via alternative methods using the login page may need to adapt by removing the input fields or removing the required attribute.

Props @joedolson for the 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, and 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..

Media

The fallback return value in get_the_author() is corrected to return an empty string if called before $authordata is set. This fixes PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher 8.1 “null to non-nullable” deprecation notice in ent2ncr() function that is hooked via the_author 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.. (#58157)

Plugins

A new plugins_list filter hook is introduced, which can be used to filter the list of plugins (including those that are “must-use / mu”) that are displayed on the WP Adminadmin (and super admin) Plugins screen. (#57278)

function wporg_filter_plugins_list( $plugins ) {
	unset( $plugins['all']['test-plugin/test.php'] );
	return $plugins;
}
add_filter( 'plugins_list', 'wporg_filter_plugins_list' );

Posts, Post Types

A new post type label item_trashed is introduced, which allows 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 to announce the correct message when an entity is moved to the TrashTrash Trash in WordPress is like the Recycle Bin on your PC or Trash in your Macintosh computer. Users with the proper permission level (administrators and editors) have the ability to delete a post, page, and/or comments. When you delete the item, it is moved to the trash folder where it will remain for 30 days.. (#51387)

Themes

Non-block themes without theme.json can opt-in to block link color tools and block border tools via add_theme_support(). (#58597 and #58598)

In the callback function that is hooked to the after_setup_theme action in your functions.php of your theme, add the following inside the function:

opt-in to block link color tools:

add_theme_support( 'link-color' );

opt-in to block border tools:

add_theme_support( 'border' );


Props to @audrasjb for the visual assets.

Users

A new wp_update_user action hook is introduced, which fires after the user has been updated and emails have been sent. (#57843)

add_action( 'wp_update_user', function ( $user_id, $userdata, $userdata_raw ) {
        echo $user_id;
        print_r( $userdata );
        print_r( $userdata_raw );
        exit;
}, 10, 3 );

Props to @costdev and @mikeschroder for technical review, to @milana_cap for review.

#6-3, #dev-notes, #dev-notes6-3

Bundled themes dropping Internet Explorer scripts and styles

Due to very low traffic from Internet Explorer users, and because WordPress no longer supports this obsolete browser, default themes have removed some IE-specific scripts and styles to give everyone else a better experience.

Most default themes had a skip-link focus fix script for navigating by keyboard in Internet Explorer and old versions of Chrome. As of WordPress 6.3, Twenty Thirteen and Twenty Fourteen no longer include it in their functions.js files, and the six themes from Twenty Fifteen to Twenty Twenty-One do not enqueue or print the script.

In addition, special stylesheets and the HTML5 Shiv script are not enqueued or included in the header.php template for three themes:

  • Twenty Thirteen (its conditional code is also removed)
  • Twenty Fifteen
  • Twenty Seventeen

Future versions of Twenty Eleven, Twenty Twelve, Twenty Fourteen and Twenty Sixteen may remove their special styles and conditional code too.

What if I want to continue supporting Internet Explorer?

Twenty Thirteen users can add a minified version of the script found in later themes:

function wpdocs_twentythirteen_add_skip_link_fix_inline() {
	wp_add_inline_script(
		'twentythirteen-script',
		'/(trident|msie)/i.test(navigator.userAgent)&&document.getElementById&&window.addEventListener&&window.addEventListener("hashchange",function(){var t,e=location.hash.substring(1);/^[A-z0-9_-]+$/.test(e)&&(t=document.getElementById(e))&&(/^(?:a|select|input|button|textarea)$/i.test(t.tagName)||(t.tabIndex=-1),t.focus())},!1);'
	);
}
add_action( 'wp_enqueue_scripts', 'wpdocs_twentythirteen_add_skip_link_fix_inline', 11 );

Twenty Fourteen would need an adjustment for the fixed headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes.:

function wpdocs_twentyfourteen_add_skip_link_fix_inline() {
	wp_add_inline_script(
		'twentyfourteen-script',
		'/(trident|msie)/i.test(navigator.userAgent)&&document.getElementById&&window.addEventListener&&window.addEventListener("hashchange",function(){var t,e=location.hash.substring(1);/^[A-z0-9_-]+$/.test(e)&&(t=document.getElementById(e))&&(/^(?:a|select|input|button|textarea)$/i.test(t.tagName)||(t.tabIndex=-1),t.focus(),window.scrollBy(0,-80))},!1);'
	);
}
add_action( 'wp_enqueue_scripts', 'wpdocs_twentyfourteen_add_skip_link_fix_inline', 11 );

Enqueue the theme’s script for Twenty Fifteen, Twenty Sixteen or Twenty Seventeen:

function wpdocs_twentyseventeen_add_skip_link_fix() {
	wp_enqueue_script( 'twentyseventeen-skip-link-focus-fix' );
}
add_action( 'wp_enqueue_scripts', 'wpdocs_twentyseventeen_add_skip_link_fix' );

Add the theme’s function to the wp_print_footer_scripts action for Twenty Nineteen, Twenty Twenty or Twenty Twenty-One:

add_action( 'wp_print_footer_scripts', 'twenty_twenty_one_skip_link_focus_fix' );

Restoring conditional code, styles and scripts

Sites may have been severely broken when using old versions of Internet Explorer, even with the HTML5 Shiv script and IE-specific styles, but you could add them again.

If you have a child themeChild theme A Child Theme is a customized theme based upon a Parent Theme. It’s considered best practice to create a child theme if you want to modify the CSS of your theme. https://developer.wordpress.org/themes/advanced-topics/child-themes/. of Twenty Thirteen, you can ensure it has a header.php template that includes the conditional code and HTML5 script from previous versions of the theme. Then you could enqueue the styles in the child theme functions (or 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).

function wpdocs_twentythirteen_ie_restore() {
	wp_enqueue_style( 'twentythirteen-ie' );
}
add_action( 'wp_enqueue_scripts', 'wpdocs_twentythirteen_ie_restore' );

For Twenty Fifteen, you could enqueue the two IE stylesheets. If a child theme does not already have the HTML5 script in a header.php template, the same function could enqueue that too.

function wpdocs_twentyfifteen_ie_restore() {
	// Enqueue stylesheets.
	wp_enqueue_style( 'twentyfifteen-ie' );
	wp_enqueue_style( 'twentyfifteen-ie7' );

	// If the header template does not have the HTML5 script already, enqueue it.
	wp_enqueue_script(
		'twentyfifteen-html5',
		get_template_directory_uri() . '/js/html5.js',
		array(),
		'3.7.0',
		false
	);
	wp_script_add_data( 'twentyfifteen-html5', 'conditional', 'lt IE 9' );
}
add_action( 'wp_enqueue_scripts', 'wpdocs_twentyfifteen_ie_restore' );

With Twenty Seventeen, both the style and script can be enqueued.

function wpdocs_twentyseventeen_ie_restore() {
	wp_enqueue_style( 'twentyseventeen-ie8' );
	wp_enqueue_script( 'html5' );
}
add_action( 'wp_enqueue_scripts', 'wpdocs_twentyseventeen_ie_restore' );

For more details, see TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets #54421 and #56699.

Props to @westonruter and @joedolson for technical review, to @stevenlinx and @audrasjb for review.

#6-3, #bundled-theme, #core-themes, #dev-notes, #dev-notes6-3

Miscellaneous Editor changes in WordPress 6.3

In this post, you will find 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, and 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. for smaller changes to the editor in WordPress 6.3.


Table of contents


Post editor iframed

From WordPress 6.3 on, the post editor will be iframed if all registered blocks have a Block API version 3 or higher. Adding version 3 support means that 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. should work inside an iframeiframe iFrame is an acronym for an inline frame. An iFrame is used inside a webpage to load another HTML document and render it. This HTML document may also contain JavaScript and/or CSS which is loaded at the time when iframe tag is parsed by the user’s browser., though the block may still be rendered outside the iframe if not all blocks support version 3.

It is worth noting that the Site Editor and Page Template Editor have always been iframed, alongside block and pattern previews, and will continue to be iframed regardless of the Block 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. version.

To make adoption easier, all assets (styles and scripts) added through the enqueue_block_assets PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher action will now also be enqueued for the iframe. For more details, see #48286.

It’s also worth noting that enqueue_block_editor_assets should not be used to add stylesheets for editor content. Please use enqueue_block_assets instead. If you don’t want styles to load on the front-end, you can use an is_admin() condition.

For backward compatibility, we will clone stylesheets added via enqueue_block_editor_assets if the stylesheet contains a .editor-styles-wrapper, .wp-block, or .wp-block-* selector, but a warning message will be logged. You should use enqueue_block_assets instead, or block.json if you’re adding block styles, theme.json for block-based themes, or add_editor_style() for classic themes.

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 developers are asked to make blocks compatible with the iframed methods and support version 3 and to report any problems with those changes. In a future version of WordPress, the editor content will load within an iframe regardless of the Block API version.

For more information about why iframing the editor content is preferred, please revisit the post Blocks in an iframed (template) editor.

Edit: there’s a new page in the Block Editor Handbook on enqueuing assets in the editor, provided by @ndiego.

Props to @ellatrix for the 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, and 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..

Publish types for plugins packages enabled

TypeScript developers appreciate having great in-editor type-hints and compiler warnings. With the changes for WordPress 6.3, contributors reduced the reliance on DefinitelyTyped, and increase code maintainability. Various wordpress packages were published to allow TypeScript to emit types by parsing the JSDoc comments.

With some small tweaks to assist its inference capabilities, TypeScript can generate extensive type definitions even for store objects without migrating much code to TypeScript. So far, the following packages are using this process now:

  • Publish rich text build types (#49651)
  • Convert wp data controls to typescript (#49647)
  • Publish build types for notices (#49650)
  • Publish types for plugins package (#49649)

The work for some larger packages is still in progress, such as blockseditor, and block-editor.

See #49649 for more details.

Props to @noahtallen for the dev note

Allow dragging-and-dropping images from the inserter to image blocks

The updates to the onDragStart prop of the <Draggable> component switched the synchronous callback function from an asynchronous one. Previously, it used to be called asynchronously with a slight delay set by setTimeout(onDragStart, 0). The previous behavior posed a limitation as users were unable to add additional data for the drag event due to security measures implemented by web browsers.

This change should have minimal impact on existing code. However, if it does affect your code, you can maintain the original behavior by wrapping your event callback inside a setTimeout function as shown below:

-onDragStart={ () => { doSomething(); } }
+onDragStart={ () => { setTimeout( doSomething, 0 ); } }

See #49673 for more details.

Props to @kevin940726 for the dev note

New slot in the site editor’s Template sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme.

Extenders can now add additional information in the site editor’s Template sidebar. With the new slot named PluginTemplateSettingPanel the information will appear below the main information, similar to below example of the Template Card. (See Code Example)

import { MyTemplateSettingTest } from '@wordpress/edit-site';
const MyTemplateSettingTest = () => (
	<PluginTemplateSettingPanel>
		<p>Hello, World!</p>
	</PluginTemplateSettingPanel>
);

For more details, see #50257.

The site editor, showing settings panel with additional slot below the template card.

Props to @ntsekouras for the dev note

New `ungroup` transforms API

Block Transforms is the API that allows a block to be transformed from and to other blocks, as well as from other entities.

From now on, via the optional transforms key of the block configuration, blocks can use the ungroup subkey to define the blocks that will replace the block being processed. These new blocks will usually be a subset of the existing inner blocks, but could also include new blocks.

If a block has an ungroup transform, it is eligible for ungrouping without the requirement of being the default grouping block. The UIUI User interface used to ungroup a block with this API is the same as the one used for the default grouping block. For the Ungroup button to be displayed, you must have a single grouped block selected, which also contains some inner blocks.

ungroup is a callback function that receives the attributes and inner blocks of the block being processed. It should return an array of block objects.

Example:

export const settings = {
    title: 'My grouping Block Title',
    description: 'My grouping block description',
    /* ... */
    transforms: {
        ungroup: ( attributes, innerBlocks ) =>
            innerBlocks.flatMap( ( innerBlock ) => innerBlock.innerBlocks ),
    },
};

For more details, see #50385.

Props to @ntsekouras for the dev note

Block variation transforms in block switcher

Block Variations is the API that allows a block to have similar versions of it, but all these versions share some common functionality. Each block variation is differentiated from the others by setting some initial attributes or inner blocks. Then, when a block is inserted, these attributes and/or inner blocks are applied.

From now on, variations with a scope: transform will be prioritized in the block switcher menu so that they are easier surfaced in existing user interface (UI) patterns. Noting that the existing UI in the block’s inspector controls regarding the variation transformations is preserved as is.

For more details, see #50139.

Props to @ntsekouras for the dev note

Prioritizing Blocks in the Inserter

In this PR, we added a way to control what blocks are shown in the block inserter for a particular block. This allows a block to suggest particular blocks which are going to be most useful.

For example, when inserting a block within the Navigation block, we specify core/navigation-link and core/navigation-link/page as these are the most commonly used inner blocks.

prioritizedInserterBlocks is a property of the InnerBlocks component. To use it, pass prioritizedInserterBlocks as a property of the options argument passed to useInnerBlocksProps.

prioritizedInserterBlocks takes an array of the form {blockName}/{variationName}, where {variationName} is optional.

As a result, the blocks you specify in prioritizedInserterBlocks should be the first ones in the block inserter:

Props to @scruffian for the dev note

Renaming Reusable Blocks to Patterns

Reusable blocks have been renamed to Patterns in WordPress 6.3. For backward compatibility, the default behavior of  core/block remains exactly the same as with Reusable blocks. The block content is still saved to the wp_block CPT and any changes to the block content are reflected across all instances of the block. This default behavior of the Pattern block is referred to in the UI as ‘synced’.

The Pattern block also has a second option in 6.3 which is ‘unsynced’. When ‘unsynced’, the block will behave the same as the existing theme and plugin patterns, i.e. the patterns blocks will be inserted as standalone blocks, and any edits affect only that instance.

In order to track the synced and unsynced status, a new postmeta field has been registered for the wp_block CPT called wp_pattern_sync_status. If this postmeta field is undefined, the pattern is considered synced, and if the pattern is unsynced, this will be set to unsynced. Because this is a coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. field, it is exposed as a top-level field in the REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. instead of a 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. property, so it will appear on the wp_block as entity.wp_sync_status.

Because the synced Patterns do not require the new postmeta field, we don’t anticipate any impact on plugins that may modify the existing reusable block behavior. The only impact we anticipate is on any plugins that manipulate the DOM based on selectors that depend on the text Reusable block(s) existing in the UI. These selectors would need to be adjusted to expect the text Pattern instead.

Props to @glendaviesnz for the dev note

Patterns on the create a new template modal

In WordPress 6.2, we introduced a new modal for creating templates. This modal presents the option to start a new template from a “blank” state or use the current fallback of the template. In WordPress 6.3, we expanded this modal’s functionality to display patterns that are suitable for a given template.

For a pattern to appear in the modal, it needs to specify a property called templateTypes, which is an array containing the templates where the patterns can be used as the full content.

Here’s an example that demonstrates adding a pattern to the start of a 404 template:

register_block_pattern(
	'my-patterns/404-template',
	array(
		'title'      => __( 'New 404 pattern', 'gutenberg' ),
		'templateTypes' => array( '404' ),
		'content'    => '<!-- wp:paragraph {"align":"center","fontSize":"x-large"} -->
						<p class="has-text-align-center has-x-large-font-size">404</p>
						<!-- /wp:paragraph -->',
	)
);

Props to @jorgefilipecosta for the dev note


Props to @bph and @annezazu for reviewing the post

#6-3, #dev-notes, #dev-notes6-3

Introducing the WordPress Command Palette API

WordPress 6.3 ships with a new command palette. Initially included in the post and site editors, users can open the command palette using the ctrl + k or command + k keyboard shortcuts.

An overview on how the command palette appears in the editor.

Registering commands

The command palette includes a number of coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. commands that you can use by default including things like:

  • Navigating the site editor.
  • Creating new posts and pages.
  • Toggling UIUI User interface elements.
  • Toggling editor preferences.
  • and more.

It also offers an 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. for third-party developers to register or unregister commands.

There are two ways to register commands: static commands and dynamic commands.

Static commands

Static commands can be registered using the wp.data.dispatch( wp.commands.store ).registerCommand action or using the wp.commands.useCommand ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. hook. Both methods receive a command object as an argument, which provides a unique name, a label, an icon, a callback function that is called when the command is selected, and potentially a context.

Example:

wp.commands.useCommand( {
	name: 'myplugin/my-command-name',
	label: __( 'Add new post' ),
	icon: plus,
	callback: ({ close }) => {
		document.location.href = 'post-new.php';
		close();
	},
} );

Dynamic commands

Dynamic commands, on the other hand, are registered using “command loaders.” These are needed when the command list depends on the search term entered by the user in the command palette input or when some commands are only available when some conditions are met.

For example, when a user types “contact”, the command palette need to 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. the available pages using that input.

function usePageSearchCommandLoader( { search } ) {
	// Retreiving the pages for the "search" term
	const { records, isLoading } = useSelect(
		( select ) => {
			const { getEntityRecords } = select( coreStore );
			const query = {
				search: !! search ? search : undefined,
				per_page: 10,
				orderby: search ? 'relevance' : 'date',
			};
			return {
				records: getEntityRecords( 'postType', 'page', query ),
				isLoading: ! select( coreStore ).hasFinishedResolution(
					'getEntityRecords',
					[ 'postType', 'page', query ]
				),
			};
		},
		[ search ]
	);

	// Creating the commands
	const commands = useMemo( () => {
		return ( records ?? [] ).slice( 0, 10 ).map( ( record ) => {
			return {
				name: record.title?.rendered + ' ' + record.id,
				label: record.title?.rendered
					? record.title?.rendered
					: __( '(no title)' ),
				icon: icons[ postType ],
				callback: ( { close } ) => {
					const args = {
						postType,
						postId: record.id,
						...extraArgs,
					};
					document.location = addQueryArgs( 'site-editor.php', args );
					close();
				},
			};
		} );
	}, [ records, history ] );

	return {
		commands,
		isLoading,
	};
}

useCommandLoader( {
	name: 'myplugin/page-search',
	hook: usePageSearchCommandLoader,
} );

Contextual commands

Commands can be contextual. This means that in a given context (for example, when navigating the site editor, or when editing a template), some specific commands are given more priority and are visible as soon as you open the command palette. And when typing the command palette, these contextual commands are shown above the rest of the commands.

At the moment, two contexts have been implemented:

  • site-editor This is the context that is set when you are navigating in the site editor (sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. visible).
  • site-editor-edit This is the context that is set when you are editing a document (template, template part or page) in the site editor.

As the usage of the command palette expands, more contexts will be added. 

To attach a command or a command loader to a given context, it is as simple as adding the context property (with the right context value from the available contexts above) to the useCommand or useCommandLoader calls.

WordPress Data API

The command palette also offers a number of selectors and actions to manipulate its state which includes:

  • Retrieving the registered commands and command loaders using the following selectors getCommands and getCommandLoader
  • Checking if the command palette is open using the isOpen selector.
  • Programmatically open or close the command palette using the open and close actions.

Props to @bph, @annezazu, and @leonnugraha for reviewing.

#6-3, #dev-notes, #dev-notes6-3

Improvements to the Cache API in WordPress 6.3

As part of the release of WordPress 6.3, the new Performance team has been working on several improvements to the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. There are a few new additions to the WordPress Cache 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., improved validation, and new actions. 

Change cache groups for all query caches

There are a number of places in WordPress where the results of queries are cached, for example, all the major query classes like WP_Query, WP_Comment_Query, and WP_Term_Query. As of WordPress 6.3, the class WP_User_Query also caches the result of queries. In previous versions, the query results were stored in the same cache group as the corresponding object. For instance, post query data would be stored in the “posts” group. However, starting from WordPress 6.3, this approach has been modified.

The update introduces new cache groups specific to queries, offering developers greater control over the handling of objects within these groups. Core functionality now enables developers to specify the expiration time for a cache group, allowing them to set a duration of, for instance, one day. If desired, developers can also use the wp_cache_flush_group() function to clear a specific cache group (if their object cache implementation supports it). Additionally, this change allows developers to designate a cache group as non-persistent, if needed. The following are the newly added cache groups:

  • post-queries
  • term-queries
  • comment-queries
  • networknetwork (versus site, blog)-queries ( global cache group )
  • site-queries  ( global cache group )
  • user-queries ( global cache group )

For sites with persistent object caching enabled, ensure that it supports wp_cache_add_global_groups function (added in WP 2.6) to add global cache groups . If not, you will have to manually add the three new global cache groups. 

See #57625 and #40613 for additional context.

New utility function wp_cache_set_last_changed()

A new utility function, wp_cache_set_last_changed(), has been introduced in WordPress 6.3. This function is utilized to update the last updated value in the cache. It complements the existing wp_cache_get_last_changed() function, which was added in WordPress 4.7. In the core codebase, all instances where the last changed value was updated have been replaced with calls to this new function.

In addition to the new utility function, a corresponding action called wp_cache_set_last_changed has been introduced. This action provides valuable information such as the cache group, the newly updated value, and the old value. Developers can leverage this action to implement custom cache invalidation strategies. When combined with the new cache groups mentioned earlier and the wp_cache_flush_group() function, it becomes possible to clear an entire cache group programmatically.

Here is some sample code of this action that can be used along with the wp_cache_flush_group() function. 

function wpdocs_cache_clear_query_groups( $group ){

  switch( $group ){

     case 'comment':

        $cache_group = 'comment-queries';

        break;

     case 'sites':

        $cache_group = 'site-queries';

        break;

     case 'networks':

        $cache_group = 'network-queries';

        break;

     case 'posts':

        $cache_group = 'post-queries';

        break;

     case 'terms':

        $cache_group = 'term-queries';

        break;

     case 'users':

        $cache_group = 'user-queries';

        break;

     default:

        $cache_group = false;

  }

  if( $cache_group ){

     wp_cache_flush_group( $cache_group );

  }

}

add_action( 'wp_cache_set_last_changed', 'wpdocs_cache_clear_query_groups' );

Validation added to  _get_non_cached_ids() for  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. IDs

The _get_non_cached_ids() function has been updated to perform validation, ensuring that only an array of unique integers are passed as input. In the previous version, no validation was conducted on the input, leading to potential validation errors and even PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher fatal errors. This function now only supports passing an array of integers. If incorrect values are passed, a _doing_in_wrong message is triggered to inform developers of the error. See #57593

Misc changes 

The PHPUnit test suite now calls wp_cache_flush_runtime() instead of manually resetting class properties of the object cache. The wp_cache_flush_runtime() function was added into core back in WordPress 6.0. If you are running the WordPress core unit tests with an object cache drop-in enabled, please ensure that the wp_cache_flush_runtime() function is present. See #31463

The function wp_cache_get_multiple was introduced in WordPress 5.5., and in WordPress 6.3, it is now in a couple of new places. It is now used to prime network options in wp_load_core_site_options in a single cache call. The wp_cache_get_multiple was also implemented in fill_descendants in WP_Comment_Query. This method is used to fill in descendant comments. This increases the performance of sites that heavily use nested comments. See #57803 and #56913

Props to @flixos90 and @joemcgill for peer review, to @stevenlinx, @leonnugraha and @jyolsna for review.

#6-3, #dev-notes, #dev-notes6-3

Social Icons block: Applied colors now dynamically update based on theme.json and Global Styles

The Social Icons 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. provides options to set both an “Icon color” and an “Icon background color”. In versions prior to WordPress 6.3, the selected colors were hardcoded as hex code values within the block, even if you chose a color from the theme palette defined in 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..

Let’s take the example of the Twenty Twenty-Three theme, where the icon color is set to “Base” and the background color to “Secondary.” The icons’ frontend markup would include inline styles like this:

<li style="color: #ffffff; background-color: #345C00;" class="wp-social-link wp-social-link-facebook wp-block-social-link">
    <a rel=" noopener nofollow" target="_blank" href="https://#" class="wp-block-social-link-anchor">
        <svg width="24" height="24">
            ...
        </svg>
        <span class="wp-block-social-link-label">Facebook</span>
    </a>
</li>

As you can see, the inline styles reflect the hardcoded hex code values for the base and secondary colors defined in Twenty Twenty-Three’s theme.json file, which are #ffffff and #345C00 respectively.

This approach caused issues when modifying the color palette in Global Styles, manually changing the theme.json file, or selecting different theme style variations. The icon colors did not update whenever the values for base or secondary were changed.

This problem is clearly demonstrated in the following video. Despite choosing different style variations, which have their own values for base or secondary, the icon colors remain fixed at #ffffff and #345C00.

To address this, WordPress 6.3 introduces CSSCSS Cascading Style Sheets. classes to the Social Icons block that correspond to the selected color values. These classes are used all over WordPress and are automatically generated based on the color palette set in the theme.json file. They follow the format:

  • has-[color_slug]-color
  • has-[color_slug]-background-color

It’s important to note that these classes will not be applied if a user selects a custom color.

With the application of these CSS classes, any changes made to the base or secondary colors in Global Styles or theme.json will be automatically reflected in the Social Icons block. Here’s an updated example of the code (scroll to the right to view the classes):

<li style="color: #ffffff; background-color: #345C00;" class="wp-social-link wp-social-link-facebook wp-block-social-link has-base-color has-secondary-background-color">
    <a rel=" noopener nofollow" target="_blank" href="https://#" class="wp-block-social-link-anchor">
        <svg width="24" height="24">
            ...
        </svg>
        <span class="wp-block-social-link-label">Facebook</span>
    </a>
</li>

Each CSS class corresponds to a specific color variable:

.has-base-color {
    color: var(--wp--preset--color--base) !important;
}

.has-secondary-background-color {
    background-color: var(--wp--preset--color--secondary) !important;
}

While these CSS classes take precedence over the hardcoded hex values, it’s important to mention that the hardcoded values are still retained. This design ensures that if a user switches to a theme that doesn’t support the base or secondary colors, the icons will still display correctly using the original hardcoded hex values.

The following video shows that the Social Icons block now updates as the user changes the theme style variation in Global Styles.

Finally, it’s worth noting that this change won’t require any action from theme developers or users unless some custom functionality has been implemented. The rendering of the Social Icons block is handled through PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher, meaning that if any updates are made to the color palette defined in theme.json and the icon or background color is set to one of the colors from that palette, the icons will automatically update to reflect the changes.

For additional context and to review the technical implementation of this change, please see #51020.

Props to @leonugraha, @juanmaguitar, and @mburridge for review.

#6-3, #dev-notes, #dev-notes6-3

Introducing the Block Selectors API

The new 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. Selectors 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. allows more flexibility in how global styles are applied to blocks. As the available design tools grow in number and complexity, not all styles can be applied neatly to a block’s wrapping element.

In WordPress 5.8, the __experimentalSelector property was introduced and later evolved to facilitate applying feature-level global styles, such as borders, colors, and typography, to arbitrary selectors. Similarly, the __experimentalDuotone property was also introduced in WordPress 5.8 to support the application of SVG filters.

As advancements in design tools continue, the need for greater control over the application of global styles has grown more pressing. It is, for this reason, the selectors API has been extended and stabilized.

New selectors API features

Through the new API, a block can configure multiple CSSCSS Cascading Style Sheets. selectors for use in generating global styles. These can be set at three different levels; root, feature, and sub-feature.

Root selectors

A root selector is the block’s primary CSS selector.

All blocks require a primary CSS selector for their global style declarations to be included under. If one hasn’t been supplied via the Block Selectors API, a default will be generated in the form of .wp-block-<name>.

Example:

{
	...
	"selectors": {
		"root": ".my-custom-block-selector"
	}
}

Feature-level selectors

This level of selector relates to styles for specific block support, such as border, color, typography, etc. They allow for a block to apply such styles to different elements within a block. For example, applying colors to the block’s wrapper but typographic styles to an inner text element.

Example:

{
	...
	"selectors": {
		"root": ".my-custom-block-selector",
		"color": ".my-custom-block-selector",
		"typography": ".my-custom-block-selector > h2"
	}
}

Subfeature selectors

These selectors relate to individual styles provided by block support e.g. background-color or border-radius.

A subfeature can now have styles generated under its own unique selector. This is most useful when a single feature’s styles need to be applied to separate elements. For example, a block’s typography might require font-family on the wrapper but text-decoration and font-size on different inner elements.

Example:

{
	...
	"selectors": {
		"root": ".my-custom-block-selector",
		"color": ".my-custom-block-selector",
		"typography": {
			"root": ".my-custom-block-selector > h2",
			"text-decoration": ".my-custom-block-selector > h2 span"
		}
	}
}

Shorthand

For convenience, instead of specifying the same selector for every subfeature, you can define a simple string at the feature level.

Fallbacks

If a selector has not been configured for a given feature, it will fall back to the block’s root selector. Similarly, if a subfeature has no custom selector set, it will fall back first to its parent feature’s selector before the block’s root selector.

A detailed example configuration and explanation can be found in the Block Selectors API reference guide.

Backwards compatibility

Blocks currently using the __experimentalSelector and __experimentalDuotone support properties will continue to function as before. 

However, if a block adds a selectors property in its block.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., that selectors configuration will be honored in its entirety. In other words, a block cannot use both the Selectors API and the old experimental properties.

Links

Props to @bph, @annezazu, @priethor and @leonnugraha for reviewing.

#6-3, #dev-notes, #dev-notes6-3

Configuring development mode in 6.3

WordPress 6.3 introduces a new concept called “development mode”, which affects certain nuances in how WordPress behaves. Going forward, sites will be able to configure their development mode using a new WP_DEVELOPMENT_MODE constant, which is recommended for any development sites.

What is the development mode?

The development mode configured on a site defines the kind of development work that the site is being used for. 

Possible values for WP_DEVELOPMENT_MODE are:

  • coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.” indicates that this site is used as a WordPress core development environment. For example, this may be relevant when you are contributing directly to WordPress core.
  • 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” indicates that this site is used as a WordPress plugin development environment. For example, this may be relevant when you are working on a plugin for the plugin repository.
  • “theme” indicates that this site is used as a WordPress theme development environment. For example, this may be relevant when you are working on a theme for the theme repository.
  • “all” indicates that this site is used as a WordPress development environment where all three aspects may be modified. For example, this may be relevant when you are working on a specific site as a whole, e.g. for a client.
  • An empty string indicates that no particular development mode is enabled for this site. This is the default value and should be used on any site that is not used for development.

Per this definition, setting a development mode is only relevant for sites where any kind of development is occurring. For example, it is not advised or relevant to use on a production siteProduction Site A production site is a live site online meant to be viewed by your visitors, as opposed to a site that is staged for development or testing..

What specifically does the development mode do?

There are currently only a few use-cases in WordPress core which are determined by the development mode, but this will likely increase in the future. Most usage today relates to theme.json caching.

It is also a great example for the kind of nuance that the development mode of a site affects:

  • On most sites, caching certain data from theme.json is reliable since that data would only be invalidated when the theme is updated.
  • However, if you are actively developing a theme on the site and modifying theme.json constantly, having to manually invalidate the cache all the time would be detrimental to the development workflow. Therefore, that specific caching functionality is bypassed if the development mode is set to “theme”.
  • On the flipside, if you are directly contributing to WordPress core (i.e. setting your development mode to “core”), your site should behave as close to the actual behavior as possible, so even though you are in a development environment as well, having the theme.json data cache bypassed would not represent the actual behavior intended for a regular WordPress site.
  • That is why that specific caching functionality is only bypassed during theme development, but not during core development.

Difference between development mode, environment type, and debug mode

WordPress already contains two seemingly related concepts, which are the environment type (WP_ENVIRONMENT_TYPE constant) and debug mode (WP_DEBUG constant). Here is how they differ:

  • WP_DEBUG (boolean) toggles general debugging mode, which results in additional notices being displayed or logged.
  • WP_ENVIRONMENT_TYPE (string) defines whether the site is a local, development, staging, or production environment. This value can be used to set defaults for other configuration parameters or toggle certain features on the site.
  • WP_DEVELOPMENT_MODE (string) defines a specific scope of development that applies to the current site, which results in certain low-level WordPress behavior to change. This is different from WP_DEBUG which does not affect actual behavior. Additionally, WP_DEBUG typically applies to any development environment, while WP_DEVELOPMENT_MODE is more specific, as explained in the aforementioned example.

It is likely that you will only use the WP_DEVELOPMENT_MODE constant on a site where WP_DEBUG is enabled and WP_ENVIRONMENT_TYPE is either “development” or “local”, since it is not advised for development to occur directly against staging or production environments. That said, the constant is still decoupled, also because it defines the kind of development that is occurring more granularly than a simple on/off switch like WP_DEBUG.

Setting the development mode for a site

To set the development mode for a site, simply add a definition of the WP_DEVELOPMENT_MODE constant to your wp-config.php file. For example, if your site is a development environment for your plugin:

define( 'WP_DEVELOPMENT_MODE', 'plugin' );

Most likely, in this case you also want to make sure you have WP_DEBUG enabled and WP_ENVIRONMENT_TYPE set to “development” or “local”.

Checking the development mode for a site

A new function wp_is_development_mode( $mode ) is the recommended way to check whether a given development mode is enabled for the WordPress site. The function expects you to pass a $mode parameter that you would like to check for (e.g. “core”, “plugin”, or “theme”) and returns a boolean for whether said mode is enabled.

Per the aforementioned list of possible values, if a site has WP_DEVELOPMENT_MODE set to “all”, the function will return true for any $mode passed.

Here is an example:

if ( wp_is_development_mode( 'theme' ) ) {
	/*
	 * This could contain some logic that only applies when developing a theme
	 * on the site.
	 */
}

Additionally to wp_is_development_mode( $mode ), another lower-level function wp_get_development_mode() has also been added in WordPress 6.3, which returns the value of the WP_DEVELOPMENT_MODE constant directly. However, accessing the constant value directly is discouraged. Due to special values such as “all” that can encompass multiple other development modes, it is advised to always use wp_is_development_mode( $mode ) instead.

If you are logged into the WP Adminadmin (and super admin) interface, you can access the current value of the WP_DEVELOPMENT_MODE constant under Tools > Site Health > Info, in the WordPress Constants section.

See #57487 for additional context on this change.

Props @peterwilsoncc for technical review, @stevenlinx for proofreading.

Update July 17, 2023: The function wp_in_development_mode() was renamed to wp_is_development_mode() after initial publication of this article (see [56249]). All references have been updated.

#6-3, #dev-notes, #dev-notes6-3

Layout updates in the editor for WordPress 6.3

Here are the 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, and 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. for layout-related changes in the editor.

Layout support stabilization and updates

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. support for layout has now graduated from experimental to stable. Everything works the same; the only difference is that when adding block support for layout in block.json, its name is now layout instead of __experimentalLayout. Support for the __experimentalLayout syntax will be maintained for a while, but it is recommended to upgrade any custom blocks using layout to the stable layout syntax. (#51434)

Code example (in block.json):

"supports": {
    "layout": true
}

Changes in CSSCSS Cascading Style Sheets. specificity for some layout types

The CSS output for the margin styles of children of constrained and flow (default) layout containers has changed. The generic rules used to have a specificity of 0,1,0 for all blocks; they have now changed to 0,0,0 for all blocks with an extra 0,2,0 rule applied only to the first and last blocks in the container.

This fixes the issue of global margin styles for specific blocks being overridden by layout styles (see #43404).

Compound block and layout type classname applied to inner wrapper of layout blocks

As of WP 6.2, layout classnames are added to the block inner wrapper. For most blocks, this is the same as the outer wrapper, but some blocks (e.g. coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Cover) have multiple inner containers. In 6.3, a new classname is added to the inner wrapper of all blocks with layout, comprised of block classname + layout classname, e.g.: .wp-block-cover-is-layout-constrained. This is the updated Cover block markup:

<div class="wp-block-cover is-light">
    <span aria-hidden="true" class="wp-block-cover__background has-tertiary-background-color has-background-dim-100 has-background-dim"></span>
    <div class="wp-block-cover__inner-container is-layout-constrained wp-block-cover-is-layout-constrained">
        <p class="has-text-align-center has-large-font-size"></p>
    </div>
</div>

This makes it possible for blocks with a complex markup structure to support custom spacing styles.

Layout definitions removed from core theme.json

The layout definitions object, which stores base styles for the layout block support, has been removed from the core theme.json (settings.layout.definitions) and moved into the internal layout support files. Extending or overriding core layout definitions was never officially supported and including those definitions in a theme theme.json file resulted in bugs such as #49914.

Create Block Theme 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 generated theme.json files that included the layout definitions object before the 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. was fixed in #50268, so theme authors are advised to remove any layout definitions that may have been inadvertently included in their theme.json files in order to prevent buggy behavior.

New Grid layout type

A new grid layout type is available, based on CSS Grid, and defaulting to an auto-fill approach with configurable column width. It is also possible to set a fixed number of columns, by using the columnCount property in the layout object. (#49018)

To create a block with a grid layout, the following needs to be added in the supports object of the block’s block.json:

"layout": {
			"default": {
				"type": "grid"
			}
		}

Layout and block spacing support added to Post Template block

Previously, the Post Template block had custom layout styles that allowed for either a “list” or a “grid” (implemented behind the scenes with CSS flex) layout, with controls living in its parent Query block.

For 6.3, layout and block spacing support have been added to Post Template, and its controls now live in the Post Template toolbar. There is still a choice of “list” and “grid” styles, but “grid” is now implemented with the grid layout type. (#49050)

Spacer block gets orientation from the parent block layout

Spacer blocks inside a flex type layout block will now use the orientation of the parent layout. It is still possible to pass Spacer an orientation value from the parent block context, but Spacer blocks inside flex layouts will prioritize the flex orientation over the context one. (#49322)

Props for co-editing to @andrewserong and review to @bph and @leonnugraha.

#6-3, #dev-notes, #dev-notes6-3