Setting to disable Layout controls

[erikjoling]

What problem does this address?

I would like to be able to disable layout controls.

What is your proposed solution?

Inside theme.json the layout setting (general and block) should decide whether the layout controls are visible. For example

{
	"settings": {
		"layout": {
			"custom": false
		}
	}
}

[erikjoling]

#31950

[jameskoster]

I'm curious to hear the reasoning for this.

[erikjoling]

I'm building custom websites for clients. And I would like to keep the interface as clean as possible. Currently I'm trying to disable as many controls as I can, mainly leaving only the color controls on block-level.

And I believe one of the goals of the theme.json is to configure "What customization options should be made available or hidden from the user." (Handbook)

[erikjoling]

Additional thought: by default inherit default layout. And if the theme-developer disables custom content width than don't show the layout options at all.

Reference to design proposal: #31950 (comment)

[gaambo]

I'm in a similar position as @erikjoling and want to disable panel for our clients, since most of the designs are very customized.
I found out, that the LayoutPanel has a check on allowEditing in the layout-support of the block - and if it's not allowed, it does not render anything. See this file/line for WordPress 5.9 (Gutenberg 11.9).

Therefore it's possible to set the support of the entire group block-type to disallow editing - which in my case fit's fine. I will set the layout attributes only in a pattern or via a custom block-variation.

addFilter(
  "blocks.registerBlockType",
  "pluginname/group",
  (settings, name) => {
    if (name !== "core/group") {
      return settings;
    }

    const newSettings = {
      ...settings,
      supports: {
        ...(settings.supports || {}),
        layout: {
          ...(settings.supports.layout || {}),
          allowEditing: false,
          allowSwitching: false,
          allowInheriting: true,
        },
        __experimentalLayout: {
          ...(settings.supports.__experimentalLayout || {}),
          allowEditing: false,
          allowSwitching: false,
          allowInheriting: true,
        },
      },
    };
    return newSettings;
  },
  20
);

This still applies the correct layout/flex-styles, but hides the LayoutPanel. I found that only adding allowEditing somehow does not work, so I also added the other keys - which are also used in other blocks.

FYI: This only works when run outside a domReady (from @wordpress/dom-ready) - I don't know why 😅

❗ Right now the layout-key is still experimental, I'm setting un-prefixed key as well - but will have to keep an eye on changes to the layout-support config.

[vyskoczilova]

Hi folks, any updates on this? Gaambo's solution works (thanks!), but I believe that this should be solved via theme.json.

I build very custom themes and clients don't want to be able to toggle with the layout width - they want to see only settings which are supported and sometimes it's pretty hard since the new features are popping out of nowhere...

[aurooba]

This is labelled as an enhancement, which I understand. But as far as people creating themes go, this is 100% a bug that should be resolved quickly.

[Luehrsen]

I've found a solution that nukes this whole panel from every block in Gutenberg from the PHP side.

/**
 * Filter block type metadata to remove unwanted output from the editor.
 *
 * @param array $metadata Metadata for the currently processed block type.
 *
 * @return array Filtered metadata.
 */
public function filter_block_type_metadata( $metadata ) {

	/**
	 * Disable the layout panel for all blocks.
	 */
	if ( isset( $metadata['supports']['__experimentalLayout'] ) ) {
		$metadata['supports']['__experimentalLayout'] = false;
	}

	return $metadata;
}
	
add_filter( 'block_type_metadata', 'filter_block_type_metadata' );

Props to @samikeijonen for putting me in the right direction!

[bph]

Seems the use case raised by @Luehrsen in core channel: "Is there a way to disable the block layout panel through theme.json without killing alignwide and alignfull?"

@carolinan wrote "Theme.json overrides the theme support, it is not possible to not use the layout setting, but add the "old" theme support."

[Luehrsen]

Seems the use case raised by @Luehrsen in core channel: "Is there a way to disable the block layout panel through theme.json without killing alignwide and alignfull?"

To be more precise: Our work requires very strict control about what an editor can customise and what is off limits. For many reasons, including legal and retaining design consistency, we cannot just teach this issue away by telling editors to ignore this field.

That is why we disable the CSS output generated by this control with remove_filter( 'render_block', 'wp_render_layout_support_flag' );. The remaining interface is a stub without function, which is at best confusing.

Again: The ability to have VERY tight control over what CSS is output in the frontend and which controls are shown to the user is absolutely essential to a lot of currently implemented use cases in the real world.

Breaking these use cases leads to only one outcome: People not updating their WordPress systems anymore and a gradual loss of trust in the systems to either updates breaking sites or WordPress being insecure (because updates are breaking sites).

[mrwweb]

Further background on why this is a bug: #36057, content switching from classic themes to block themes appear broken because of the default behavior

See also: #33374 for impact on alignment options of nested blocks

[jffng]

I think there are a few different suggestions being discussed, I want to try and clarify the use cases:

1. Hide the layout controls on a per block and global basis via theme.json as you can with other settings (original issue)
2. Apply a specific layout config (e.g. the default one) automatically on a per block and global basis via theme.json: Setting to disable Layout controls #31980 (comment)
3. Control / disable the CSS output by the layout config: Setting to disable Layout controls #31980 (comment)

I agree 1 and 2 seem reasonable and would be useful, though there are probably some considerations I'm missing. One related issue I don't think mentioned yet is over here #36082 with some mockups on how the layout controls could be improved.

I am not sure I captured 3 correctly, or if it needs more clarification:

Again: The ability to have VERY tight control over what CSS is output in the frontend

@Luehrsen how are you suggesting the layout CSS to be modified? Or is it just the ability to disable it entirely?

[Luehrsen]

@Luehrsen how are you suggesting the layout CSS to be modified? Or is it just the ability to disable it entirely?

Hey @jffng, thank you for asking. Right now I'm in the "deactivate it completely" camp. But my stance is a result from this panel giving a lot of power to editors and it generating a lot of ugly, repetitive CSS output in the body.

[pattyok]

I agree we should be able to disable this entirely, AND also maintain control over the width settings for inner blocks. As a theme developers we all have our own systems for managing widths of blocks. We need the ability to offer minimal options when appropriate but this is not a control that I want to leave wide open to site editors. It also generates so much unnecessary CSS in the body of the page...

[chthonic-ds]

I agree we should be able to disable this entirely, AND also maintain control over the width settings for inner blocks.

I agree with this.

I have a theme using CSS Grid for all layout, integrated with the "Inherit default layout" toggle. This approach to layout means a child container is not necessarily constrained by the width of its parent container — a noted limitation of the current layout model using max-width with horizontal auto margins. There are times when the Layout panel could be/should be a valid option but Gutenberg doesn't expose it. In this situation, it would be ideal to opt-in a specific block for layout support: for example, perhaps via an attribute added to a block's markup in a pattern or template.

Theme developers will benefit from more control over where (opt-in; globally or targeted) and if (enable/disable) layout support is available.

[chrisvanpatten]

I would also like the ability to disable this field. It is confusing that you can't add "__experimentalLayout": false in the block config within theme.json. I would simply expect the following to disable the panel:

...
  "core/column": {
    "__experimentalLayout": false
  },
...

Strangely, this doesn't work even though it seems like it should.

[jg314]

If you're looking to disable the Layout panel for one specific block type, here's an example using the Column block. This is similar to what @Luehrsen provided, except it focuses on one block type, instead of all of them.

function filter_metadata_registration( $metadata ) {

	if ( $metadata['name'] === 'core/column' ) {

		$metadata['supports']['__experimentalLayout'] = false;
	}

	return $metadata;
};
add_filter( 'block_type_metadata', 'filter_metadata_registration' );

Ideally this would be possible in theme.json, but this works in the meantime.

[tcmulder]

You can also accomplish this via JavaScript on a block-by-block basis:

wp.hooks.addFilter(
	'blocks.registerBlockType',
	'my-block/attribute/options',
	(settings, name) => {
		if (name === 'core/column') {
			settings.supports = {
				...settings.supports,
				__experimentalLayout: false,
				layout: false,
			};
		}
		return settings;
	}
);

[tellthemachines]

Thanks for the feedback everyone!

Disabling layout controls via theme.json has been implemented in #53378.

For those seeking to remove layout styles altogether, that's already possible since WP 6.1 with add_theme_support( 'disable-layout-styles' ); in the theme's functions.php.

In order to disable the controls from theme.json, the required property is allowEditing: false. This property can be added in settings.layout to disable the controls for all blocks, or in settings.blocks.[block name] to disable for specific blocks.

This is can already be used with the Gutenberg plugin and will be available in core in WP 6.4.

[rose18Developer]

I'm in a similar position as @erikjoling and want to disable panel for our clients, since most of the designs are very customized. I found out, that the LayoutPanel has a check on allowEditing in the layout-support of the block - and if it's not allowed, it does not render anything. See this file/line for WordPress 5.9 (Gutenberg 11.9).

Therefore it's possible to set the support of the entire group block-type to disallow editing - which in my case fit's fine. I will set the layout attributes only in a pattern or via a custom block-variation.

addFilter(
  "blocks.registerBlockType",
  "pluginname/group",
  (settings, name) => {
    if (name !== "core/group") {
      return settings;
    }

    const newSettings = {
      ...settings,
      supports: {
        ...(settings.supports || {}),
        layout: {
          ...(settings.supports.layout || {}),
          allowEditing: false,
          allowSwitching: false,
          allowInheriting: true,
        },
        __experimentalLayout: {
          ...(settings.supports.__experimentalLayout || {}),
          allowEditing: false,
          allowSwitching: false,
          allowInheriting: true,
        },
      },
    };
    return newSettings;
  },
  20
);

This still applies the correct layout/flex-styles, but hides the LayoutPanel. I found that only adding allowEditing somehow does not work, so I also added the other keys - which are also used in other blocks.

FYI: This only works when run outside a domReady (from @wordpress/dom-ready) - I don't know why 😅

❗ Right now the layout-key is still experimental, I'm setting un-prefixed key as well - but will have to keep an eye on changes to the layout-support config.

@gaambo Thank you! the code works to hide the layout UI controls, but is there a way to toggle off 'Inner blocks use content width' by default, so the div is full width instead of set to constraint?

[gaambo]

@rose18Developer Since WordPress 6.4 there's a new allowEditing property under the layout configuration theme.json. See the dev notes: https://make.wordpress.org/core/2023/10/17/miscellaneous-editor-changes-in-wordpress-6-4/ and also #53378

If you're still using the previous workaround, in the past I've used those keys:

          allowEditing: false,
          allowSwitching: false,
          allowInheriting: true,
          allowSizingOnChildren: false,

[rose18Developer]

@rose18Developer Since WordPress 6.4 there's a new allowEditing property under the layout configuration theme.json. See the dev notes: https://make.wordpress.org/core/2023/10/17/miscellaneous-editor-changes-in-wordpress-6-4/ and also #53378

If you're still using the previous workaround, in the past I've used those keys:

          allowEditing: false,
          allowSwitching: false,
          allowInheriting: true,
          allowSizingOnChildren: false,

Thanks @gaambo ! The code help to hide the UI control, but by default, the 'Inner blocks use content width' is enabled, making the div constraint, screenshot below:

I want by default to toggle off the 'Inner blocks use content width', so the container is full width, screenshot below:

Is there a way to toggle of the 'Inner blocks use content width' when the core group block is added?

Thanks!

[tellthemachines]

@rose18Developer that's a bit trickier because the layout for the default Group type is set in its variations, which are used when inserting a new block.

You could potentially create a new variation and set it as default; see these docs for more info.

Edit: you would want your variation to have the default layout type, instead of constrained which it currently uses.