Add blockStatesEnabled setting to hide the block-level style states control

[vedant-ere]

What this does

Adds a new blockStatesEnabled editor setting that lets plugins and site owners hide the block-level Style States control in the block inspector. This is the control that lets you select a viewport or pseudo-state (such as Hover or Focus) when styling an individual block.

---

Why

Gutenberg's Style States feature is exposed through two different UI surfaces:

• Global controls, including the Responsive styles option in the View menu and the viewport selector in Global Styles.
• Per-block controls, provided by BlockStatesControl in the block inspector for supported blocks (such as the Button block).

Issue #80814 introduced the responsiveEditingEnabled setting, allowing developers to disable the global Style States UI. This is useful for plugins or themes that provide their own state-styling experience and want to opt out of the built-in interface.

However, there was no equivalent setting for the per-block control. The only workaround was to target the internal CSS class (.block-editor-global-styles-state-control) directly. Since that class is an implementation detail rather than a public API, it can change or be removed at any time, making it an unreliable solution for production use.

This change closes that gap by introducing a supported blockStatesEnabled setting, giving the block inspector the same clean opt-out mechanism already available for the global Style States UI.

Closes: #80850

---

How to use it

Configure the setting through the standard block_editor_settings_all filter:

add_filter( 'block_editor_settings_all', function ( $settings ) {
	$settings['blockStatesEnabled'] = false;
	return $settings;
} );

The setting defaults to true, so existing behavior is unchanged unless it's explicitly disabled. When set to false, BlockStatesControl is simply not rendered in the block inspector.

This setting only affects the visibility of the UI for selecting style states. It does not affect existing state data or rendering:

• Existing Style States saved in block content continue to work normally.
• Those styles continue to render correctly in both the editor and on the frontend.
• No block attributes, saved content, or data migrations are involved—this is purely a UI visibility toggle.

---

Implementation

The implementation follows the same pattern already used by codeEditingEnabled and responsiveEditingEnabled.

File	Change
packages/editor/src/store/defaults.js	Adds blockStatesEnabled: true as the default editor setting and documents it alongside the other *Enabled settings.
packages/editor/src/components/provider/use-block-editor-settings.js	Forwards the setting from the editor package to the block-editor package, following the existing pattern used for codeEditingEnabled.
packages/block-editor/src/store/defaults.js	Documents the setting in the block editor settings typedef.
packages/block-editor/src/components/block-inspector/index.js	Reads the setting and skips rendering <BlockStatesControl /> when blockStatesEnabled is false.

---

Testing instructions

1. Insert a block that supports Style States (the Button block is the easiest to test).
2. Select the block and open the Settings sidebar.
3. Verify that the Style States control appears next to the block name.
4. Add the filter above to a must-use plugin or your theme's functions.php, then reload the editor.
5. Select the same block again and confirm that the Style States control is no longer shown.
6. If the block already has a state (for example, Hover) configured, verify that those styles still render correctly in both the editor canvas and the published post.
7. Remove the filter, reload the editor, and confirm that the Style States control reappears.

---

AI Usage: Claude was used to understand the codebase and assist with implementation.

[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: vedant-ere <vedantere@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]

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Required label: Any label starting with [Type].
• Labels found: .

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

[github-actions]

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @vedant-ere! 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.