Allow to disable settings for specific blocks

[vyskoczilova]

What problem does this address?

Please, think about tailor-made themes that are coded from design to WordPress.

We need to control block settings being to able to turn off user's modifications like Layout and Width panels (and other "new features"). There is no way to turn them off and they are causing many headaches - clients call you "why it doesn't work in our theme", but the designer hasn't prepared those options. And the reason why this happens is that the new WordPress is released. I mean - I want to use the latest release, but I don't want to use certain features that are not ready in design.

I haven't found a way to do it.

Looks like it's related to #19796 that was never solved.

What is your proposed solution?

Add theme.json settings that will easily allow setting panels off - in settings for all blocks, in blocks for separate blocks. I believe that theme.json should be the place for all edits. That would enable to quickly disable unwanted features and at the same time keep latest WP version.

[fabiankaegy]

This is also something that comes up again and again on client builds. The ability to control which settings get presented to the editor via a mechanism like theme.json already is great for all the settings that can be shown/hidden that way. The width settings panel of the button block is one of the few remaining ones that doesn't have a way to show/hide it.

In a way, I see this setting as similar to the dropCap setting. It doesn't really have a reason to exist at a global scale because the only block that actually implements it is the core/paragraph block. But it still exists as an option in theme.json.

The way this could be done without refactoring the width setting to be a block support like all the other settings, would be by using useSetting( 'layout.width' )

[karthick-murugan]

Hi everyone,

I wanted to revisit this issue as it seems to still be relevant for many developers and clients dealing with tailored themes. After reviewing the previous comments and updates, it looks like there hasn’t been a concrete resolution or a native mechanism to disable certain block settings like the Width panel for the core/button block in theme.json.

I see there was some progress with PR #42079 in 2022 to add support for toggling Width settings, but from what I can tell, it hasn't yet made its way into core. I wanted to check if there are any new global settings or updates that might now allow for this functionality, or if this is still being tracked under useSetting('layout.width') as mentioned earlier.

I’d love to hear if anyone has found workarounds or other methods to manage this in the meantime. If this still needs a formal solution, I’d be happy to help with testing or contributing to the discussion on a potential fix. Do we think that revisiting the initial proposal in PR #42079 is the best way forward, or are there newer approaches in Gutenberg that could help address this issue?

Looking forward to hearing your thoughts!

cc: @roseg43 , @bph , @jordesign , @skorasaurus , @fabiankaegy , @Mamaduka , @vyskoczilova

[karthick-murugan]

Hello everyone,

I would like to seek clarification on the following points regarding this ticket:

1. Initially, the focus was on core buttons, but now it is mentioned as "specific blocks." Could you please confirm if this refers to all default Gutenberg blocks, or if there are specific blocks you are referring to? If the latter, specifying the block names would be helpful for reference.

2. Considering you need to disable setting for all Gutenberg blocks. If we add following snippet, in the current active theme.json file, it should disable width properties of Core button block ?

"blocks": {
   "core/button": {
      "spacing": {
         "width": false
      }
   }
}

Similarly, if you want to disable the padding setting for the Core Paragraph block, it would look like this:

"blocks": {
   "core/paragraph": {
      "spacing": {
         "padding": false
      }
   }
}

cc:@vyskoczilova

[vyskoczilova]

@karthick-murugan Thanks for picking it up, although the WP is in difficult times now.

1. Yes, generally speaking, all the default blocks and default "features." The possibility of turning a particular feature off at one place, passing a "false" attribute, would be fantastic. It doesn't matter if it's padding, width, color, or whatever.

2. Yes, exactly. And setting it off on the general level would disable it for every block:

"settings": {
      "spacing": {
         "width": false
      }
}

[karthick-murugan]

Thanks for your feedback @vyskoczilova

I have checked the following code to effectively disable specific settings for default blocks in a custom theme:

wp.hooks.addFilter(
    'blocks.registerBlockType',
    'custom-theme/disable-block-settings',
    (settings, name) => {
        // Define the blocks and their corresponding settings to disable
        const disabledBlocks = {
            'core/paragraph': ['typography', 'color', 'spacing', '__experimentalBorder'], // Disable typography and spacing for Paragraph block
            'core/button':    ['typography', 'color' ,'spacing', '__experimentalBorder', 'shadow'], // Disable settings for Button block
            'core/heading':   ['typography', 'color', 'spacing', '__experimentalBorder'], // Disable settings for Heading block
            'core/quote':     ['typography', 'color', 'spacing', '__experimentalBorder','background','dimensions'], // Disable settings for Quote block
        };

        // Check if the block name is in the disabled blocks list
        if (disabledBlocks[name]) {
            settings.supports = settings.supports || {};

            // Loop through the settings to be removed for the block
            disabledBlocks[name].forEach((setting) => {
                delete settings.supports[setting];
            });
        }

        return settings;
    }
);

This code allows for selective disabling of unnecessary settings for various default blocks, such as the Paragraph, Button, Heading, and Quote blocks. By defining the blocks and their respective settings to be disabled in the disabledBlocks object, developers can easily customize the editor experience in their themes.

To implement this, simply include the code in a separate JavaScript file or within your theme's custom JavaScript file. Please note that this code does not affect the button width settings, which come from the edit.js file in the InspectorControls, as they are not included in the block.json file. Therefore, I have created a separate PR to address that specific issue.

I would greatly appreciate any feedback or suggestions from fellow core developers regarding this implementation. Thank you for your time!

[vyskoczilova]

Hi @karthick-murugan,

Thank you for the JavaScript and your efforts on the InspectorControls issue. However, I still view this as a temporary solution. Ideally, the configuration should be managed in the theme.json file, and setting it to false seems logical.

Additionally, maintaining this code and tracking down where and how the feature is disabled could become quite time-consuming. This should be a default part of the theme.json instead of a workaround in JavaScript.

This is where using a simple FSE/Gutenberg theme can become frustrating. There are too many touchpoints to manage, and it is often unclear which interface to use for enabling or disabling features, whether it’s theme.json, PHP, or JavaScript.

[karthick-murugan]

Thanks @vyskoczilova for your feedback.

In the context of customising block styles via theme.json, we can see that using a JSON object like the one below, we can disable or modify various options in the "Styles" tab for specific blocks:

"blocks": {
	"core/paragraph": { 
		"color": {
			"custom": false,   
			"palette": [],
			"background": false
		},
		"typography": {
			"customFontSize": false,
			"fontSizes":[],
			"fontFamilies": [],
			"lineHeight": false,
			"letterSpacing": false,
			"textDecoration": false,
			"textTransform": false,
			"dropCap": false,
			"fontStyle": false,
			"fontWeight": false,
			"writingMode": false
		},
		"spacing": {
			"padding": false,
			"margin": false
		},
		"border": {
			"radius": false,
			"width": false,
			"color": false
		}
	},
	"core/button": { 
		"color": {
			"custom": false,   
			"palette": [],
			"background": false
		},
		"typography": {
			"customFontSize": false,
			"fontSizes":[],
			"fontFamilies": [],
			"lineHeight": false,
			"letterSpacing": false,
			"textDecoration": false,
			"textTransform": false,
			"dropCap": false,
			"fontStyle": false,
			"fontWeight": false,
			"writingMode": false
		},
		"spacing": {
			"padding": false,
			"margin": false
		},
		"border": {
			"radius": false,
			"width": false,
			"color": false,
			"style": false
		},
		"shadow": {}
	},
	"core/image": { 
		"color": {
			"custom": false,   
			"palette": [],
			"duotone": []
		}
	}
},

Using the above json object in current active theme's theme.json file, we can disable the following. Similarly we can follow the same approach for all of the default blocks for the options that are not needed by theme authors in the "Styles" tab.

1. Paragraph:
Color
Typopgraphy
Spacing
Border
2. Button:
Color
Typopgraphy
Spacing
Border
3. Image
Color

The "Styles" tab in the block editor allows users to configure the visual styling of blocks (such as typography, color, spacing, borders, etc.). Using the theme.json file, theme developers can customize and disable all options within the "Styles" tab.

On the other hand, the "Settings" tab contains controls for block behavior, such as alignment options, toggle features (like enabling or disabling captions), and other block-specific functionalities. Unlike the "Styles" tab, the options in the "Settings" tab are not configurable via theme.json or block.json.

The reason for this is that "Settings" controls are more user-specific and pertain to the content or functional aspect of blocks, rather than their appearance. These settings allow the editor to adjust the behavior of the block while editing content, and they are context-sensitive to how the block is used.

So for Settings tab of all default blocks, need some ideas to move forward.