Disable Width Settings in Button Block

[karthick-murugan]

What?

Fixes Part of this issue

This PR introduces the ability to disable the button block's width settings through the theme.json file.

Why?

This functionality is important for themes that are tailored to specific designs, where controlling the button width setting may be unnecessary or undesired. This provides better flexibility for theme developers, allowing them to disable the width controls as needed.

How?

The edit.js file of the button block has been updated to retrieve the width value from the theme’s theme.json file. If the width setting is disabled (i.e., set to false), the width panel is no longer displayed in the editor for the button block.

Testing Instructions

1. Checkout this branch to your local

2. Include the following JSON object within the settings section of the theme.json file for the active theme:

"blocks": {
	"core/button": [
		{
			"width": false
		}
	]
},

3. Now insert button block in the editor and check the width Settings of the button and it will be removed. Just update false to true in theme.json and check the width Settings and it can be seen.

Testing Instructions for Keyboard

None

Screenshots or screencast

For no changes in theme.json or adding width value to true

For theme.json width value false

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: karthick-murugan <karthickmurugan@git.wordpress.org>
Co-authored-by: carolinan <poena@git.wordpress.org>
Co-authored-by: justintadlock <greenshady@git.wordpress.org>
Co-authored-by: ndiego <ndiego@git.wordpress.org>
Co-authored-by: youknowriad <youknowriad@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @karthick-murugan! In case you missed it, we'd love to have you join us in our Slack community.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.

[carolinan]

Hi @karthick-murugan
When changes are made to theme.json, the theme.json schema must also be updated.
I mean that the schema must reflect that setting the width to false is valid.
https://github.com/WordPress/gutenberg/blob/trunk/schemas/json/theme.json

[justintadlock]

Good job! I like the forward movement toward handling this pretty common request (disabling block settings).

Aside from the theme.json schema update, I'd want to be very cautious about introducing methods for disabling block settings. I feel like there's probably an architectural decision that should be made on how to best do this for any block's setting. If we introduce one-off settings for individual blocks like this, does this create legacy code that we have to support? I don't know the answer to that, but I think it's worth asking. I'm not sure what the best path is, but this needs a decision.

[ndiego]

Aside from the theme.json schema update, I'd want to be very cautious about introducing methods for disabling block settings. I feel like there's probably an architectural decision that should be made on how to best do this for any block's setting. If we introduce one-off settings for individual blocks like this, does this create legacy code that we have to support? I don't know the answer to that, but I think it's worth asking. I'm not sure what the best path is, but this needs a decision.

+1 to this. If the approach in this PR is correct, I could see this being applied to all block settings. This is a very common feature request. But we need to make sure this is the correct course of action more broadly. Thoughts on this from an architectural standpoint @youknowriad @mtias?

[youknowriad]

theme.json is the right approach for these things but I wouldn't tie this to a block. We should think about "block supports" more globally.

• What other blocks have a "width" control?
• Should we add a "width" block support and support it for more blocks? I think the answer is probably yes, I can also see the need for a maxWidth, minWidth block support too. (maybe they're enabled/disabled together)
• It's ok for blocks to have inconsistent implementation for "width" (history reasons or valid reasons)
• It also seems like we already have a dimensions.minHeight config in theme.json (I wish this was just dimensions.height kind of but I guess it's ok to have both later.

Based on this, I think I'd be ok having a dimensions.width config in theme.json to enable/disable all width controls regardless of blocks (and obviously you can do it for a given block if needed just like any setting).

I would love if we can do an audit of existing "width" controls in the core blocks to see if it adapts to all of these.

Now for the implementation, the following should probably be enough to retrieve the right config for a given block.

const [ isWidthEnabled ] = useSettings( 'dimensions.width' );

[youknowriad]

width and height block supports are tracked here #28356

[ndiego]

The Columns block is another good candidate for this. The width should be part of the Dimensions panel.

[carolinan]

The search block has a width option too