Block layout: Wide and Full are not available for custom container blocks if __experimentalLayout: constrained is used

[CreativeDive]

Tested in Gutenberg 14 RC2.

The wide and full options for the inner blocks will only appear if a content width is defined, which can be done by the theme, in the global styles interface or on the block itself.
Check if your theme's theme.json has something like "layout": { "contentSize": "840px", "wideSize": "1100px"} in its settings object. If it doesn't, and you haven't defined content sizes anywhere in the block or the global styles editor, then "wide" and "full" options won't appear for children.

@tellthemachines thank you, it's very important to know how the things should be working to test if everything is working fine or not.

Now I can get you the full bug report.

Test Case 1: Custom container block

1. "layout": { "contentSize": "840px", "wideSize": "1100px"} is set in theme.json.
2. "__experimentalLayout": { "type": "constrained" } is set in the block.json inside the support object.
3. Add a new block (in that case my custom container block).
   ----> "Inner blocks respect content width" is NOT enabled by default.
   ----> Is this a bug ? 🐛

Test Case 2: Custom container block

1. Same like in test case 1.
2. But additionally "attributes": { "layout": { "type": "object", "default": { "type": "constrained" } } }, is set in the block.json
3. Add a new block (in that case my custom container block).
   ----> "Inner blocks respect content width" is enabled by default.
4. Copy the block and look inside the block code:
   ----> The block code does not contain"type":"constrained"
   --------> I think that is correct and expected.

Test Case 3: Custom container block

1. Same like in test case 1.
2. But additionally "attributes": { "layout": { "type": "object", "default": { "type": "constrained" } } }, is set in the block.json
3. Add a new block (in that case my custom container block).
   ----> "Inner blocks respect content width" is enabled by default.
4. Set a custom content size in the sidebar field.
   ----> The inner blocks get the width from the content size field
5. Copy the block and look inside the block code:
   ----> The block code contains "type":"constrained"
   --------> I think that is correct and expected.
6. Add a core/cover block to the inner block component of this block.
7. You say when a content size is entered, "wide" and "full" should be available for child blocks. I wish it would be like this.
   ----> But it does not work! It seems it's a BUG! 🐛 ‼️

I will now test the same with the core/group block to see a comparison.

Originally posted by @CreativeDive in #33374 (comment)

[CreativeDive]

@tellthemachines Here is the same report, but instead I use the core/group block.

Test Case 1: Core group block

1. "layout": { "contentSize": "840px", "wideSize": "1100px"} is set in theme.json.
2. "__experimentalLayout": { "type": "constrained" } is set in the block.json inside the support object.
3. Add a new block (in that case the core/group block).
   ----> "Inner blocks respect content width" is enabled by default.
   --------> I think that is correct and expected.
4. Copy the block and look inside the block code:
   ----> The block code contains "type":"constrained"
   --------> I think that is correct and expected.
5. Add a core/cover block to the inner block component of this block.
6. You say when a content size is entered, "wide" and "full" should be available for child blocks.
   ----> But, the "wide" and "full" options are available also without set a content size in the sidebar
   ----> Is this a bug ? 🐛

Test Case 2: Core group block

1. Same like in test case 1.
2. Set a custom content size in the sidebar field.
   ----> The inner blocks get the width from the content size field
3. You say when a content size is entered, "wide" and "full" should be available for child blocks.
   ----> The "wide" and "full" options are available.
   --------> I think that is correct and expected.

@tellthemachines It's nice that the core/group children's blocks now also have "wide" and "full" available. But it is NOT the case for our custom blocks. But it must be available for inner blocks. This is exactly what I and many others expect. Can you reproduce this?

SIDE NOTE: If my custom container block is nested inside the core/group block, the "wide" and "full" are available. But not inside my custom container block. Is there a limitation and can it be fixed or activated by an additional setting?

[CreativeDive]

@tellthemachines Another bug. 🐛

Adding a new custom container block, with the following settings in the block.json:

"attributes": { "layout": { "type": "object", "default": { "type": "constrained" } } },
"__experimentalLayout": { "type": "constrained" }

1. The block starts with "Inner blocks respect content width" is enabled by default.
   --------> I think that is correct and expected.
2. The block class name in the block editor source code contains is-layout-constrained.
   --------> I think that is correct and expected.
3. Save the post and look at the front end output.
4. The block class name in the front end source code contains is-layout-flow.
   ----> It's a BUG! 🐛 ‼️

Only if I manually change the "Inner blocks respect content width" toggle to OFF and back to ON, the expected class name is-layout-constrained appears in the front end block output.

[CreativeDive]

@andrewserong thanks for response. I have now separated it and created a new issue.

[tellthemachines]

Thanks for the detailed report @CreativeDive !

I've worked out the problem with Test Case 1: Custom container block: it's that inside support in block.json we instead need to set "__experimentalLayout": { "default": {"type": "constrained" }}. I must have written it down wrong in the original PR, sorry about that!

The issue with "wide" and "full" not being available for child blocks does seem like a bug; I'm still looking into it.

[CreativeDive]

@tellthemachines thanks a lot. Nice to get wide and full blocks back again for our custom container blocks!

[tellthemachines]

Ok, so it turns out the wide and full issue is also a quirk of the current implementation. In order for the inner blocks to know what alignments they're supposed to have, we need to explicitly pass a layout object to useInnerBlocksProps. An example of how that works is in the Group block edit function. A simplified version of it for this use case would be:

import { useBlockProps, useInnerBlocksProps, useSetting } from '@wordpress/block-editor';

export default function Edit( { attributes: { layout = {} } } ) {
	const layoutSettings = useSetting( 'layout' ) || {};
	const usedLayout = ! layout?.type
		? { ...layoutSettings, ...layout, type: 'constrained' }
		: { ...layoutSettings, ...layout };
	const blockProps = useBlockProps();
	const innerBlocksProps = useInnerBlocksProps(
		blockProps,
		{
			__experimentalLayout: usedLayout,
		}
	)
	return (
		<div { ...innerBlocksProps }/>
	);
}

This doesn't feel like an ideal API, and I think we should explore ways of improving it so that, like other block supports, we don't need to manually feed the settings to the inner blocks. However, we're two weeks away from Beta 1 for the next release so it's unlikely this will be addressed before the cutoff. Layout support is still an experimental feature, so we can technically still make breaking changes to it, but this gets harder to do the more folks use it for their custom blocks 😅

My best advice here is go ahead and use this if you're keen to experiment (and let us know if anything doesn't work as expected! this type of feedback is very valuable) but please keep an eye out for future changes, especially until Layout becomes a stable feature.

[CreativeDive]

@tellthemachines @carolinan @annezazu

I totally disagree with this decision. We are not all React developers and a large number of WordPress users depend on your decisions. You took away "wide" and "full" for inner blocks with the introduction of theme.json. We would like to have it back finally. Because we currently can't change our inner blocks to "wide" or "full".

Is this really a decision that you want to limit Wordpress users not to change a block to full width just because it is an inner block?

Please reconsider your decision and give us back "wide" and "full" for inner blocks. We need it! We need it now, not months or years later. 🙏

You want a user feedback for this experimental feature. But many users who don't use the group core block can't give you any feedback. The WordPress world is not just a group block. We also use other custom blocks and can't test the new feature if it doesn't work.

[CreativeDive]

@tellthemachines I would prefer to discuss the reasons why it would be better for user feedback to get this feature working in 6.1.

[ghost]

Hi there,
is there by now a simple way of having innerBlocks have the wide and full align option?
I am creating my blocks with ACF and block.json. Is there a setting in block.json that will allow innerBlocks to have the align settings in the toolbar?

[CreativeDive]

@sascha-bleech I feel with you. The issue has been reported for months, but it seems nobody here is interested in identifying and fixing real user issues. I have raised the issue several times, but there is absolutely no progress to be seen here.

[tellthemachines]

Closing as this has been fixed in #47477