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.5.

---

Table of contents

1. New Block Supports
2. Footnotes support for Custom Post Types
3. DependencyExtractionWebpackPlugin: Drop webpack4 and node<18
4. Enable Block Renaming support for (almost) all blocks
5. Stabilization of the block editor’s RecursionProvider API
6. Support for new allowedBlocks field in block.json
7. Add new selectors to fetch entity revisions
8. New useSettings hook for reading block instance settings
9. Introduction of the PluginPostExcerpt Slot Component
10. Changes to the underlying Composite component implementation
11. Deprecated components
12. Setting to disable custom content size controls

---

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. Supports

Background image block support additional features for size, repeat, and position

In WordPress 6.5, the background image block support receives new controls related to the size of the background image: size, repeat, and position.

For blocks that use the background image block support (currently, the Group block is the only coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. block to use this support), these optional controls can now be displayed. They are hidden by default behind the tools panel menu in the Background controls on the inspector 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..

How to add backgroundSize support to a theme

There are two ways to add support for backgroundSize and the related size, as well as repeat and position control to a block theme. The simplest one is to opt into the appearanceTools setting, which automatically enables a number of design tools (read more in the developer handbook).

For themes that wish to have more granular control over which UIUI User interface tools are enabled, the backgroundSize support can be opted into by setting settings.background.backgroundSize to true in theme.json. For example:

{
	"settings": {
		"background": {
			"backgroundImage": true,
			"backgroundSize": true

Note that as of WordPress 6.4 and WordPress 6.5, the backgroundImage, backgroundSize, and related supports are only available at the individual block level, not in global styles or at the site root. These features will be explored in subsequent releases, with progress tracked in this GithubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged by the repository owner. https://github.com/ issue: #54336.

GitHub pull request: #57005

Props to @andrewserong for writing 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..

Aspect ratio block support

A new aspect ratio block support has been added in WordPress 6.5, with the Cover block opted-in by default. For themes using the appearanceTools feature in theme.json, the control will be available in the inspector controls under Dimensions.

The feature allows users to set an aspect ratio for the Cover block, and is mutually exclusive with min-height rules. If an aspect ratio is set, then min-height is unset to ensure that height rules do not conflictconflict A conflict occurs when a patch changes code that was modified after the patch was created. These patches are considered stale, and will require a refresh of the changes before it can be applied, or the conflicts will need to be resolved. with the aspect ratio. The aspect ratio rules will be output at render-time for the block via an inline style applied to the block’s wrapper.

Note that themes or blocks that add width or height rules to a block will need to take care in testing compatibility with aspect-ratio if they are to opt-in to aspect ratio support. The aspect ratio tends to work most flexibly when width or height rules are not set.

How to add aspectRatio support to a theme

There are two ways to add support for aspectRatio to a block theme. The simplest is to opt into the appearanceTools setting, which automatically enables a number of design tools (read more in the developer handbook).

For themes that wish to have more granular control over which UI tools are enabled, the aspectRatio support can be opted into by setting settings.dimensions.aspectRatio to true in theme.json. For example:

{
	"settings": {
		"dimensions": {
			"aspectRatio": true

GitHub pull request: #56897

Props to @andrewserong for writing the dev note.

Add block gap support to Quote block

The Quote block has blockGap support in WordPress 6.5. It also changes the default spacing between the quote and the citation in block themes that have blockGap enabled, to be consistent with all other blocks that use the layout support. The default spacing will now use the layout spacing rules defined by a theme’s styles.spacing.blockGap value in theme.json.

For themes that use blockGap but wish to use a different gap between the quote and the citation, they can set a spacing.blockGap value for the block directly.

GitHub pull request: #56054

Props to @andrewserong for writing the dev note.

Add padding and margin support to the Pullquote block

Pullquote block now supports padding and margin. At the same time, the browser default margin applied to the blockquote element inside the block has been reset to zero to ensure that padding values are applied accurately inside the block. Depending on themes, this effect may result in visual changes and the need to adjust padding or margin.

GitHub pull request: #45731

Props to @wildworks for writing the dev note.

Footnotes support for Custom Post Types

In WordPress version 6.5, footnotes are now supported on any custom post typeCustom Post Type WordPress can hold and display many different types of content. A single item of such a content is generally called a post, although post is also a specific post type. Custom Post Types gives your site the ability to have templated posts, to simplify the concept. that fulfills certain requirements. To be eligible for footnotes, a custom post type must have capabilitiescapability A capability is permission to perform one or more types of task. Checking if a user has a capability is performed by the current_user_can function. Each user of a WordPress site might have some permissions but not others, depending on their role. For example, users who have the Author role usually have permission to edit their own posts (the “edit_posts” capability), but not permission to edit other users’ posts (the “edit_others_posts” capability). like 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/, custom fields, revisionsRevisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision., and editor support. If a post type meets these requirements, footnotes should be available by default without requiring any changes from the developer.

However, if a developer wants to remove footnotes support in a specific condition, for example, in a particular post type, they can use 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. like any other block. The following code sample demonstrates how we can remove footnotes support from the “post” post type:

add_filter( 'allowed_block_types_all', 'footnotes_allowed_block_types', 10, 2 );
 
function footnotes_allowed_block_types( $allowed_blocks, $editor_context ) {
    if( 'post' === $editor_context->post->post_type ) {
		$allowed_blocks_array = array();
		if ( is_array( $allowed_blocks )) {
			$allowed_blocks_array = $allowed_blocks;
		} else if( $allowed_blocks === false ) {
			return false;
		} else if ($allowed_blocks === true ) {
			$block_types = WP_Block_Type_Registry::get_instance()->get_all_registered();
			foreach( $block_types as $block_type) {
    			$allowed_blocks_array[] = $block_type->name;
			}
		}
	
        $allowed_blocks = array_values( array_diff( $allowed_blocks_array, array(
        'core/footnotes',
        ) ) );
    }
    return $allowed_blocks;
}

GitHub pull request: #57353

Props to @jorgefilipecosta for writing the dev note.

DependencyExtractionWebpackPlugin: Drop webpack4 and node<18

As webpack4 doesn’t support modules that blocks require to work, and that webpack5 was released more than three years ago, the support for webpack4 is dropped in WordPress 6.5.

In addition, the support for Node.js version 17 or older is dropped, as Node.js 18 is currently the oldest maintained version.

• @wordpress/scripts version 17 has dropped official support for unmaintained Node.js versions. The oldest supported Node.js version is now Node.js 18.
• @wordpress/dependency-extraction-webpack-plugin version 5 has dropped official support for unmaintained Node.js versions. The oldest supported Node.js version is now Node.js 18.
• @wordpress/dependency-extraction-webpack-plugin version 5 has dropped support for webpack versions less than 5. Users should either upgrade to webpack v5 or continue to use v4 of the 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.. Version 4 will not be maintained going forward.
  If you’re using @wordpress/dependency-extraction-webpack-plugin via @wordpress/scripts, the webpack change should not affect you.

GitHub pull request: #57303

Props to @jonsurrell for writing the dev note.

Enable Block Renaming support for (almost) all blocks

Building on the foundation introduced in WordPress 6.4, all blocks (with some exceptions) can now be given custom names within the Editor.

The data for this continues to be stored under the name property of the block’s metadata attribute (e.g. attributes.metadata.name).

All blocks (including 3rd party blocks) will be “renameable” by default, with the only exceptions being the following blocks:

• core/block
• core/template-part
• core/pattern
• core/navigation
• core/navigation-link

To disable the ability to rename a block, set the relevant support property to false in block.json:

// block.json
{
	"supports": {
		"renaming": false // disables ability to rename block via the Editor UI
	},
}

GitHub pull request: #54426

Props to @get_dave for writing the dev note.

Stabilization of the block editor’s RecursionProvider API

Context

Originally implemented as an experimental hook named __experimentalUseNoRecursiveRenders  in early 2021, then improved and repackaged in 2022 as the pair __experimentalRecursionProvider and __experimentalUseHasRecursion, the purpose of these APIs is to prevent certain advanced block types from accidentally triggering infinite rendering loops inside the block editor. For example, the Template block must guard against these loops:

• If a user adds an instance of the Template block into the contents of that same template (linear recursion);
• If Template A contains Template B, which then contains Template A (mutual recursion).

As of today, the following core block types use the RecursionProvider API: 

• core/block
• core/navigation
• core/post-content
• core/template-part.

Changes with WordPress 6.5

The API has been promoted to stable, thereby shedding the __experimental prefix. Consumers should now use the API by importing RecursionProvider and useHasRecursion from @wordpress/block-editor, or via the WP global as wp.blockEditor.RecursionProvider and wp.blockEditor.useHasRecursion.

For more details and a working example, see the component’s README.md document.

Before	After
wp.blockEditor.__experimentalRecursionProvider	wp.blockEditorRecursionProvider
wp.blockEditor.__experimentalUseHasRecursion	wp.blockEditor.useHasRecursion

Backwards compatibility

The former identifiers — __experimentalRecursionProvider and __experimentalUseHasRecursion — are now deprecated. This means that they are still accessible, but their use will trigger a warning in the browser console.

GitHub pull request: #58120

Props to @mcsf for writing the dev note.

Support for new allowedBlocks field in block.json

WordPress 6.5 adds support for the new allowedBlocks field in the block.json file. It lets block developers specify which block types can be inserted as children of the given block. It’s a companion to the existing parent and ancestor fields that have a similar function, namely specifying allowed parent block types. Example of usage in a block.json file:

{
  "name": "core/list",
  "title": "List",
  "allowedBlocks": [ "core/list-item" ]
}

One of the main advantages of the block.json field is that it can be modified by plugins. For example, you can create a block that acts as a custom list item and extend the Core List block so that your custom block can be inserted as its child:

addFilter( 'blocks.registerBlockType', 'my-list-item', ( settings, name ) => {
  if ( name === 'core/list' ) {
    const { allowedBlocks = [] } = settings;
    return { ...settings, allowedBlocks: [ ...allowedBlocks, 'my/list-item' ] };
  }
  return settings;
} );

This new API replaces the allowedBlocks option that can be passed to the useInnerBlocksProps hook inside the block’s edit function. This option was previously used to implement the same check, but it wasn’t extensibleExtensible This is the ability to add additional functionality to the code. Plugins extend the WordPress core software.: the list of allowed blocks was hardcoded in the block’s edit function and couldn’t be modified.

The allowedBlocks option on the useInnerBlocksProps hook is still supported and is not deprecated, but you should use it only for specialized use cases. Like when the list of allowed blocks is dynamically calculated for each block: from its attributes, or from its surrounding environment (the parent block etc.).

GitHub pull request: #58262

Props to @jsnajdr for writing the dev note.

Introducing the block_core_navigation_listable_blocks 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.

WordPress 6.5 introduces a new filter, block_core_navigation_listable_blocks which is designed to provide control over the accessible rendering of child blocks used within the Navigation block.

Historically, the Navigation block has conditionally wrapped particular blocks in <li> tags to ensure accessible markup on the front of the site.

With the introduction of the new allowedBlocks API, which technically allows any block to be added as valid children of the Navigation block, developers require a means to indicate which blocks need to be wrapped.

The block_core_navigation_listable_blocks filter allows developers to determine whether a specific block should be wrapped in an <li> 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.), thereby aiding in adherence to accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) standards and the creation of valid markup.

The example below shows the mycustomblock/icon block opting into being wrapped in an <li> tag:

function add_icon_block_to_navigation_listable_blocks( $blocks ) {
    $blocks[] = 'mycustomblock/icon';
    return $blocks;
}
add_filter( 'block_core_navigation_listable_blocks', 'add_icon_block_to_navigation_listable_blocks' );

GitHub pull request: #55551

Props to @get_dave for writing the dev note.

Add new selectors to fetch entity revisions

Two new selectors have been introduced to Block Editor’s Core Data API to fetch revisions and single revisions for post types that support revisions, for example, posts and pages, templates, and global styles.

getRevisions( kind, name, recordKey, query ) – fetches a post’s revisions where recordKey is the id of the parent post.

getRevision(kind, name, recordKey, revisionKey, query) – fetches a single post revision, where revisionKey is the id of the individual revision.

The functions use similar arguments to existing core data entity functions, such as getEntityRecords with the addition of recordKey (post parent id) and revisionKey (single revision id).

Example usage:

// Returns a collection of revisions.
// `parentGlobalStylesId` is the id (int) of the parent post.
wp.data.select( 'core' ).getRevisions( 'root', 'globalStyles', parentGlobalStylesId, { per_page: -1 } );
 
// Paginated results.
// `parentId` is the id (int) of the parent post.
wp.data.select( 'core' ).getRevisions( 'postType', 'post', parentId, { per_page: 3, page: 2 } )
 
// Get a single revision object.
// `parentId` is the id (int) of the parent post.
// `revisionId` is the id (int) of the individual revision post.
wp.data.select( 'core' ).getRevision( 'postType', 'post', parentId, revisionId );
 
 
// Get a single revision with only the id, parent and date fields.
// `parentId` is the id (int) of the parent post.
// `revisionId` is the id (int) of the individual revision post.
wp.data.select( 'core' ).getRevision( 'postType', 'post', parentId, revisionId, { _fields: 'id,parent,date' } );

getRevisions and getRevision can also be used via useSelect in ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org components:

import { useSelect } from '@wordpress/data';
import { store as coreStore } from '@wordpress/core-data';

function MyComponent() {
    const pageRevisions = useSelect(
        ( select ) =>
            select( coreStore ).getRevisions( 'postType', 'page', pageId ),
        [ pageId ]
    );
    // Do something with pageRevisions...
}

In the background, these selectors’ corresponding resolvers call revisions REST API endpoints.

GitHub pull request: #54046

Props to @ramonopoly for writing the dev note.

New useSettings hook for reading block instance settings

When trying to improve the block editor’s performance for WordPress 6.5, one of the identified issues was related to the useSetting hook that is used by block instances to read various settings provided by the environment they are in: parent blocks, the theme, the block editor itself. It turns out that it’s inefficient to read multiple settings with separate useSetting calls:

const allowFixed = useSetting( 'position.fixed' );
const allowSticky = useSetting( 'position.sticky' );

The editor performance is improved when all the settings are read at once using a new hook called useSettings:

const [ allowFixed, allowSticky ] = useSettings( 'position.fixed', 'position.sticky' );

That’s why WordPress 6.5 introduces this new hook. The useSetting (singular) hook is now deprecated (using it will trigger a console warning), because reading even a single setting is very easy with the useSettings (plural) hook:

const [ allowFixed ] = useSettings( 'position.fixed' );

The only change is that the useSettings hook always returns an array, and the array needs to be destructured to read the single value. Supporting two APIs for performing the same task is therefore not justified.

GitHub pull request: #55337

Props to @jsnajdr for writing the dev note.

Introduction of the PluginPostExcerpt Slot Component

This update introduces a new PluginPostExcerpt slot component within the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ editor. This enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. allows for the extension of the Post ExcerptExcerpt An excerpt is the description of the blog post or page that will by default show on the blog archive page, in search results (SERPs), and on social media. With an SEO plugin, the excerpt may also be in that plugin’s metabox. panel, allowing developers to customize this area for their needs.

What’s New?

The component enables the addition of custom content within the Post Excerpt panel. This is particularly useful for plugins looking to add extra functionality or information specific to their use case.

Usage

To utilize this new feature, developers can now insert their custom content into the Post Excerpt panel by creating a component that leverages the slot. This allows for a seamless integration of custom functionalities directly within the editor.

The following example shows adding custom content to the post excerpt panel.

import { PluginPostExcerpt } from '@wordpress/edit-post';
import { __ } from '@wordpress/i18n';

const MyPluginPostExcerpt = () => (
  <PluginPostExcerpt
    className="my-plugin-post-excerpt"
  >
    { __( 'Post excerpt custom content' ) }
  </PluginPostExcerpt>
);

GitHub pull request: #55200

Props to @retrofox for writing the dev note.

Changes to the underlying Composite component implementation

WordPress 6.5 no longer includes the Reakit package, as it does not support React beyond v16. The __unstable* Composite component was built on this library, so it has been internally refactored.

What does this mean for consumers?

The primary API has not changed, and can still be imported with no changes. For typical usage patterns, there should be no differences, and in most cases, no action is required from consumers of the package.

However, composite state props must now be generated by the useCompositeState hook; they can no longer be provided by independent state logic. Composite state arguments have not changed, though, and will continue to work as before.

import {
  __unstableComposite: Composite,
  __unstableCompositeGroup: CompositeGroup,
  __unstableCompositeItem: CompositeItem,
  __unstableUseCompositeState: useCompositeState
} from '@wordpress/components';

const state = useCompositeState({ ... });

// ✅ This will continue to work
...( <Composite { ...state } /> );

// ⛔️ This will no longer work
...( <Composite { ...state } currentId={ ... } /> );

Consumers can continue to either spread the state or pass as a single state prop.

// ✅ Used by spreading the state
...(
  <Composite { ...state }>
    <CompositeGroup { ...state }>
      <CompositeItem { ...state }>
        { ... }
      </CompositeItem>
    </CompositeGroup>
  </Composite>
);

// ✅ Or with a single `state` prop
...(
  <Composite state={ state }>
    <CompositeGroup state={ state }>
      <CompositeItem state={ state }>
        { ... }
      </CompositeItem>
    </CompositeGroup>
  </Composite>
);

Because the shape of the returned composite state has changed, consumers can also now no longer destructure specific state props from useCompositeState.

// ✅ This will continue to work
const state = useCompositeState({ ... });

// ⛔️ This will no longer work
const { groups, items } = useCompositeState({ ... });

What’s next?

We anticipate a new stable Composite component to be released in WordPress 6.6, along with the deprecation of this unstable version.

GitHub pull request: #58620

Props to @andrewhayward for writing the dev note.

Deprecated components

Deprecating isPressed in Button component

The isPressed prop on the Button component implicitly sets aria-pressed, with no way to override it. But sometimes Button is used for roles other than button, such as option and checkbox, where aria-pressed is not appropriate, and workarounds are required to add the correct semantics.

In an effort to move away from custom props that have native HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. equivalents, and to allow greater flexibility in component usage, aria-pressed is now supported as a first-class prop, taking precedence over isPressed.

GitHub pull request: #54740

Props to @andrewhayward for writing the dev note.

Outer Margins Deprecation

A number of UI components currently ship with styles that give them top and/or bottom margins. This can make it hard to reuse them in arbitrary layouts, where you want different amounts of gap or margin between components. To better suit modern layout needs, we are in the process of deprecating these outer margins

A few releases ago, we deprecated the outer margins on a number of components and introduced transitional props so consumers could opt into these new styles before they become the default:

• AnglePickerControl: __nextHasNoMarginBottom
• CustomGradientPicker: __nextHasNoMargin
• FontSizePicker: __nextHasNoMarginBottom
• GradientPicker: __nextHasNoMargin

In WordPress 6.5, these margin-free styles have become the default. Any use of these props can be safely removed.

GitHub pull request: #58699, #58700, #58701, #58702

Props to @mikachan for writing the dev note.

CustomSelectControl deprecation

CustomSelectControl used to have a hard-coded width, which was inconsistent with our other form components. In WordPress 6.1, we deprecated this unconstrained width, and introduced the transitional __nextUnconstrainedWidth prop so consumers could opt into these new styles before they become the default.

In WordPress 6.5, these unconstrained width styles have become the default. Any use of the __nextUnconstrainedWidth prop can be safely removed.

GitHub pull request: #58974

Props to @mikachan for writing the dev note.

Remove deprecation warnings for __next36pxDefaultSize

A few releases ago, we introduced a __next36pxDefaultSize prop on several components, meant to coordiate the transition to a new default sizing scheme (36px height). Due to some changes in our design direction, we eventually dropped this prop in favor of the __next40pxDefaultSize prop (40px height), making all existing opt-ins to the __next36pxDefaultSize prop act as an opt-in to the 40px one.

After receiving developer feedback about this ahead of WordPress 6.5, we will no longer throw a deprecation warning for usages of the __next36pxDefaultSize prop, informing consumers of this change. Do note, however, that it will trigger the new 40px size rather than the 36px size, despite the prop name.

GitHub pull request: #58703

Props to @mikachan for writing the dev note.

Remove unused buttonBehavior attribute from the Search block

The Search block had a buttonBehavior attribute, which was referenced internally to determine the display variations of the block. However, this attribute was removed because it could not be changed from the user interface, and the default value was always referenced.

With this change, this attribute will no longer be referenced even if it has been added manually.

GitHub pull request: #53467

Props to @wildworks for writing the dev note.

Setting to disable custom content size controls

Similar to the setting that allows disabling layout controls in WP 6.4, this allows only the content and wide size controls for a constrained layout to be disabled from 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, globally or at a per-block level.

To disable the control globally for all blocks, add the following in theme.json under settings.layout:

"allowCustomContentAndWideSize": false

To disable at the block level, add the following in theme.json under settings.blocks:

"core/group": {
	"layout": {
		"allowCustomContentAndWideSize": false
	}
}

Props to @isabel_brison for writing the dev note.

---

Props to @fabiankaegy and @bph for reviewing the post

#6-5, #dev-notes, #dev-notes-6-5