Hide Additional CSS controls when block is inside contentOnly editing mode

[Shekhar0109]

What?

Hide Additional CSS related controls when a block is rendered inside template preview (contentOnly editing mode).

Closes #76429

Why?

When blocks are edited inside template preview, they run in contentOnly editing mode.
In this mode, controls like Additional CSS, Additional CSS Classes, and HTML Element rely on block attributes that cannot be persisted.

Currently these controls are still rendered in the Advanced panel even though their values cannot be saved. This makes the UI misleading.

How?

This PR detects when the editor is inside a content-only section using getEditedContentOnlySection.

When this mode is active, the InspectorControls.Slot for the advanced group is not rendered, preventing Additional CSS related controls from appearing.

Template Part specific controls (such as Title and Area) remain unaffected.

Testing Instructions

1. Open the Site Editor.
2. Go to Appearance → Editor → Templates → Single Posts.
3. Select a block like Post Title inside the template preview.
4. Open the Advanced panel in the block inspector.

Expected result

The following controls should not appear:

• Additional CSS
• Additional CSS Classes
• HTML Element

Verify normal editor still works

1. Go to Posts → Add New.
2. Insert any block.
3. Open the Advanced panel.

The following controls should still appear:

• HTML Anchor
• Additional CSS Classes
• Additional CSS

[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: Shekhar0109 <[email protected]>
Co-authored-by: t-hamano <[email protected]>
Co-authored-by: Mamaduka <[email protected]>
Co-authored-by: talldan <[email protected]>
Co-authored-by: fabiankaegy <[email protected]>

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

[t-hamano]

Thanks for the PR!

1. Open the Site Editor.
2. Go to Appearance → Editor → Templates → Single Posts.
3. Select a block like Post Title inside the template preview.
4. Open the Advanced panel in the block inspector.

In my testing, the Advanced panel is visible and the Additional CSS field is editable. Am I missing something?

[Shekhar0109]

@t-hamano Thanks for reviewing!

I re-tested the change using the local wp-env environment.

When a block is rendered inside a template preview (contentOnly editing mode), such as blocks inside a Template Part, the Additional CSS related controls are no longer rendered in the Advanced panel.

For example, selecting Header → Site Title in the Site Editor shows only Template Part specific controls:

• Title
• Area
• HTML Element

The following controls are no longer displayed:

• Additional CSS
• Additional CSS Classes
• HTML Anchor

I also verified that the normal editing experience remains unchanged.
When editing blocks in the main template content, the Advanced panel still displays the standard controls such as Additional CSS and Additional CSS Classes.

Screenshots are attached showing both scenarios.

[t-hamano]

This approach seems to work fine in the site editor, but not in the post editor.

Wouldn't it be sufficient to just add useBlockEditingMode, as with many other block supports?

diff --git a/packages/block-editor/src/hooks/custom-css.js b/packages/block-editor/src/hooks/custom-css.js
index 5bd3347726e..096d9ba93df 100644
--- a/packages/block-editor/src/hooks/custom-css.js
+++ b/packages/block-editor/src/hooks/custom-css.js
@@ -17,6 +17,7 @@ import AdvancedPanel, {
 } from '../components/global-styles/advanced-panel';
 import { cleanEmptyObject, useStyleOverride } from './utils';
 import { store as blockEditorStore } from '../store';
+import { useBlockEditingMode } from '../components/block-editing-mode';
 
 // Stable reference for useInstanceId.
 const CUSTOM_CSS_INSTANCE_REFERENCE = {};
@@ -33,6 +34,12 @@ const EMPTY_STYLE = {};
  * @param {Object}   props.style         Block style attribute.
  */
 function CustomCSSControl( { blockName, setAttributes, style } ) {
+       const blockEditingMode = useBlockEditingMode();
+
+       if ( blockEditingMode !== 'default' ) {
+               return null;
+       }
+
        const blockType = getBlockType( blockName );
 
        function onChange( newStyle ) {

[Shekhar0109]

@t-hamano Thanks for the suggestion!

I updated the implementation following your recommendation.

Instead of hiding the entire Advanced panel, I restored the original AdvancedControls behavior and moved the check to CustomCSSControl using useBlockEditingMode.

This ensures that the Custom CSS control is hidden when the block editing mode is not default, while keeping the Advanced panel and other controls unaffected.

Please let me know if this approach looks correct or if further adjustments are needed.

[t-hamano]

LGTM!

[t-hamano]

@Shekhar0109 The reason the E2E test failed is that this pull request changed the sidebar tabs in the navigation editor.

Before

After

We should be able to fix this problem by reverting this code: https://github.com/WordPress/gutenberg/pull/73959/changes#diff-cb34a8a792e758a928744e7e7afc59c026bf81670d1fec5961398cdf8b4d7e0b

[Shekhar0109]

@t-hamano Thanks for the review and approval!

I’ve pushed a follow-up fix addressing the earlier Playwright failure. It looks like the current failures are in PHP unit tests, which don’t seem directly related to this change (as this PR only modifies JavaScript in the block editor).

I’ll keep an eye on the logs, but please let me know if you’d like me to investigate further.

[Shekhar0109]

@t-hamano I’ve applied the suggested revert so the code matches the previous behavior.

Since the Playwright-6 failure appears unrelated to this change, I’ll wait for the further guidance.

[t-hamano]

Since the Playwright-6 failure appears unrelated to this change, I’ll wait for the further guidance.

No, the Playwright-6 failure is related to this PR. See #76512 (comment)

[t-hamano]

Thanks for the update! I believe all CI checks should be ✅.

[t-hamano]

The failing E2E test is completely unrelated to this PR. Please see the PRs below.

• Fix navigation block unit test and e2e test #76692
• RTC: Change RTC option name #76643 (comment)

[github-actions]

I just cherry-picked this PR to the wp/7.0 branch to get it included in the next release: fddf7db