Template Part block: Stopped displaying block option controls (since WP7.0)

Description

My theme is enabling additional block settings for Template Part block. Namely supports.dimensions.minHeight, support.position.sticky, and support.spacing.margin. (This is done both via JS and via PHP code.)

Everything works perfectly fine with WordPress 6.9.

Since WordPress 7.0 (and also tested with Gutenberg 23.3.2 enabled) the block option controls no longer display.
Although the block theme enhancements are still registered and working correctly, as they still produce desired results when adding the attributes in block code, such as:

<!-- wp:template-part {
	"slug": "header",
	"tagName": "header",
	"className": "is-style-site-header",
	"anchor": "masthead",
	"style": {
		"spacing": {
			"margin": {
				"top": "0",
				"bottom": "0"
			}
		}
	}
} /-->

So, the issue is really only about option controls not displaying for the Template Part block anymore.

Expected behavior:

Option controls should display
as it was the case with WordPress 6.9
and as it is the case with other blocks the theme extends (for example, there is background and border enabled for Site Logo block, which works perfectly fine even in WordPress 7.0).

Step-by-step reproduction instructions

In WordPress 6.9 with Zooey theme installed, open 404 template for editing in Site Editor.
Select header template part and try to edit its options in sidebar:
You can see there are additional (theme-enabled via JS and PHP) options displayed (margin, height, position).
Now repeat the steps for WordPress 7.0 and compare:
You can see the options disappeared.

Screenshots, screen recording, code snippet

WordPress 6.9 + Zooey (the expected behavior):

WordPress 7.0 + Zooey (buggy):

Environment info

WordPress 6.9 and 7.0
Zooey theme
also tried with WP7.0 + Zooey + Gutenberg 23.3.2 - the result is the same as just WP7.0 + Zooey

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

Please confirm which theme type you used for testing.

Block
Classic
Hybrid (e.g. classic with theme.json)
Not sure

Some more debug info: The issue was introduced in Gutenberg 22.5.0.

Previous versions work OK.

@andrewserong

Since WordPress 7.0 (and also tested with Gutenberg 23.3.2 enabled) the block option controls no longer display.

In my understanding, this is the expected behavior in 7.0. To edit the template part block itself, you need to click the "Edit original" button to move to the template part editor.

Just to double-check. @andrewserong @talldan @ramonjd

That's my understanding. Which means that a user can only edit the internals of the template part rather than styles attached to the template part instance.

My theme is enabling additional block settings for Template Part block. Namely supports.dimensions.minHeight, support.position.sticky, and support.spacing.margin. (This is done both via JS and via PHP code.)

Unfortunately what this theme is doing goes against the decisions made in Gutenberg for how template parts work. This block intentionally didn't opt in to these block supports because setting styles on the template part instance (as it's inserted within a template) proved confusing for users.

Before offering a suggestion on how to get back to the previous behaviour, I did just want to mention that it's inherently risky to opt core blocks in to features that haven't been used yet. There is a high likelihood of breakage across releases (as in this case). If core blocks don't offer the features desired for your theme, it might be worth considering either a) writing custom blocks to fulfill what you'd like or b) proposing enhancements to blocks in Gutenberg so that they can be improved canonically.

All of that said, I think it might still be possible for a theme to override the block editing mode to return to the behaviour prior to 7.0. I think it'd be a matter of doing something like this (please note, I haven't tested this, this is just an idea):

       // Opt the Template Part block out of the WP 7.0 "section" (content-only)
        // editing experience, so its block-support controls stay visible in the
        // inspector. Other blocks are untouched.
        const withTemplatePartControls = createHigherOrderComponent(
                ( BlockEdit ) => ( props ) => {
                        useBlockEditingMode(
                                props.name === 'core/template-part' ? 'default' : undefined
                        );
                        return createElement( BlockEdit, props );
                },
                'withTemplatePartControls'
        );

        addFilter(
                'editor.BlockEdit',
                'zooey/restore-template-part-controls',
                withTemplatePartControls
        );

If we find that this is a common use case (intending to disable content only for the template part block), then we might want to add disableContentOnlyForTemplateParts to the BLOCK_EDITOR_SETTINGS array. Essentially a similar PR to: #75457

(Also, keen to hear if anyone has other ideas — this is all just off the top of my head after a few days off 😄)

then we might want to add disableContentOnlyForTemplateParts to the BLOCK_EDITOR_SETTINGS array

Thanks for raising this idea - it's arisen more than once, and was the motivation behind #77923 as well.

I can empathize with the view that the content only locking can disrupt current work flows, and I think power users need to be able to turn it off when creating pages, e.g., to drag between patterns and so on.

On the topic of block option controls, patterns do show block styles:

Makes me wonder if template parts should as well, though it's now pretty crowded with the list view/content/settings tabs.

On the topic of block option controls, patterns do show block styles ... Makes me wonder if template parts should as well, though it's now pretty crowded with the list view/content/settings tabs.

Though only unsynced patterns support styles.

Synced patterns are the same as template parts in not supporting styles for the same reason - it can be confusing to understand whether a change was applied globally or locally. Having said that I think it was more confusing before when a user could always edit the internal blocks in a template part.

If we find that this is a common use case (intending to disable content only for the template part block), then we might want to add disableContentOnlyForTemplateParts to the BLOCK_EDITOR_SETTINGS array.

This is already implemented.

This is already implemented.

Is it? I can only see disableContentOnlyForUnsyncedPatterns, not an entry for disableContentOnlyForTemplateParts, so I assumed the block editor setting was only supported for unsynced patterns but not template parts. I haven't manually checked, though!

I see disableContentOnlyForTemplateParts, not 100% sure if it can be overridden via filter though... I think no (?) because it's declared after the BLOCK_EDITOR_SETTINGS spread?

I see disableContentOnlyForTemplateParts, not 100% sure if it can be overridden via filter though... I think no (?) because it's declared after the BLOCK_EDITOR_SETTINGS spread?

Interesting. I guess that's a mistake. Probably easy enough to open it up to allow overriding the default.

FWIW, I'll also look into fixing OPs issue, there's probably no reason to block extenders from adding whatever they want, especially if it was supported before.

The original intention in #74793 (which introduced the issue) was to make Template Parts less restricted than patterns by showing the settings tab, so it wasn't intentionally locked down, just an unfortunate side effect.

It will mean the tabs are a little crammed in, we haven't typically supported four tabs on one block before.

I see disableContentOnlyForTemplateParts, not 100% sure if it can be overridden via filter though... I think no (?) because it's declared after the BLOCK_EDITOR_SETTINGS spread?

I looked into this and you were right about it not being overridden via filter. The setting was being stripped out because it was missing from the BLOCK_EDITOR_SETTINGS allowlist array in use-block-editor-settings.js

I have worked up a fix for this (adding it to the array) along with the relevant Redux test coverage. I'll open a separate issue for it and link my PR there.

Hi everyone and thank you for your feedback! I will provide specific replies below for better readability and reference.

@t-hamano

@t-hamano & @ramonjd

In my understanding, this is the expected behavior in 7.0. To edit the template part block itself, you need to click the "Edit original" button to move to the template part editor.

I don't have a problem with content-only editing mode, actually. Please note that I don't want to edit the template part block content.

My issue is related to Template Part block wrapping its content in a <div> (or other HTML block tag), and my enhancements allow me/user to style this wrapper <div> container.

Maybe if there was an option to disable this <div> wrapper, there would no issue I'm experiencing. (Basically the Template Part block would behave just like a block pattern.)

The wrapper <div> is actually the biggest difference between block patterns and template parts for me, and I treat template parts as sections to design the actual theme templates. (Maybe I still see it through classic theme glasses?) And I use block patterns for page/post content.

@andrewserong

@andrewserong

Before offering a suggestion on how to get back to the previous behaviour, I did just want to mention that it's inherently risky to opt core blocks in to features that haven't been used yet.

I understand that and I took this risk. Simply because I was used to build classic themes, where I had more control, so I wanted to provide similar control for a block theme. I wanted to move forward towards building block themes and yet I couldn't really recreate what I was able to with classic themes...

I also consider Template Part block to be more advanced-user block, unlike a block pattern. If I'm not mistaken, Template Part block can only be used in Site Editor, not in page/post block editor, so it is meant as part of website structure and design. That's how I approach it.

However, if this Template Part block behavior was intentional from the start, maybe it should not produce the wrapper <div>. It caused issues for my designs which I resolved by enhancing the block support.

I went through a lot of challenges porting my classic themes behavior/functionality into block theme paradigm and logged quite a number of Gutenberg issue tickets. I make living creating WordPress themes so the time was essential to me and what I could resolve myself, I didn't ask for from Gutenberg - which is the same approach I used with WordPress for all those years.

I will try not to enhance Template Part block for my future themes (except the block styles) and find some alternative workarounds.

And thank you for the code, I will check how it works.

@ramonjd

@ramonjd

On the topic of block option controls, patterns do show block styles... Makes me wonder if template parts should as well, though it's now pretty crowded with the list view/content/settings tabs.

Yes, Template Part block displays a block style selector - check the first screenshot I provided in the issue description. I use these block styles (applied directly onto Template Part block wrapper) to hook additional theme functionality, so having block styles enabled on Template Part block is also essential for me.

@talldan

@talldan

FWIW, I'll also look into fixing OPs issue, there's probably no reason to block extenders from adding whatever they want, especially if it was supported before.

Thank you, that would be really life-saving! :)
As currently I'm quite stuck with editing the Template Part block in code view only (for my themes that introduce these block enhancements).

However, if this Template Part block behavior was intentional from the start, maybe it should not produce the wrapper
. It caused issues for my designs which I resolved by enhancing the block support.

Yep, the wrapper is a tricky one. One option is to make it like a synced pattern where there's no wrapper element on the frontend. I think such a thing could be achieved by adding a 'None' option to the 'HTML Element' dropdown in the 'Advanced' panel:

However in the editor a wrapping element is still needed at the moment for features like block selection and drag and drop. So I'm not sure it'd help.

I'd say this would be a welcome enhancement: a theme developer can decide whether to use the wrapper produced by Template Part block or not. As it would be possible to use Group block to produce a wrapper with desired styles withing template part content then.

Now when the wrapper is produced, developer expects the block to provide at least some basic options to style it. I'd say the ability to set anchor, margin and min-height (useful when a template part is displayed within flexbox container) could be the minimum. And from my perspective the margin setup is really crucial as it provides option to override block gap for a specific template part.

I think the wrapper in Site Editor would be acceptable in the case of "None" selected for "HTML Element" option for Template Part block.

However, in my particular issue I'd really like to re-enable the options for the Template Part block to make it backwards compatible.

I understand that and I took this risk. Simply because I was used to build classic themes, where I had more control, so I wanted to provide similar control for a block theme. I wanted to move forward towards building block themes and yet I couldn't really recreate what I was able to with classic themes...

Thanks for expanding on this, and glad to know you're aware of the issues involved! I was mostly just wanting to check that you'd thought of the different options 👍

However, if this Template Part block behavior was intentional from the start, maybe it should not produce the wrapper
. It caused issues for my designs which I resolved by enhancing the block support.

To my knowledge (or memory) it wasn't really the intention from the start, but more that the challenges of working with the block became more apparent over time (what's baked into the template part itself, versus what lives at the instance level). I still think we need to be able to support block styles for the template part block (just as you're trying to do with your theme, etc) and you make very valid points about the value of being able to style template parts directly.

Possibly the problem here is that we might want to be able to do all of the above:

Be able to set element type + block styles at the "root" level of a template part so that it outputs those rules across all instances of it
Be able to override this at the instance level
Possibly also support a "none" wrapper

I'm not too sure how we get there, though... but we're not alone in discussing it! Here are a few related issues:

Navigation Menu

Repository navigation

Template Part block: Stopped displaying block option controls (since WP7.0) #79152

Description

Expected behavior:

Step-by-step reproduction instructions

Screenshots, screen recording, code snippet

Environment info

Please confirm that you have searched existing issues in the repo.

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Please confirm which theme type you used for testing.

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Template Part block: Stopped displaying block option controls (since WP7.0) #79152

Description

Description

Expected behavior:

Step-by-step reproduction instructions

Screenshots, screen recording, code snippet

Environment info

Please confirm that you have searched existing issues in the repo.

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Please confirm which theme type you used for testing.

Activity

webmandesign commented on Jun 12, 2026

t-hamano commented on Jun 14, 2026

andrewserong commented on Jun 14, 2026

ramonjd commented on Jun 15, 2026

talldan commented on Jun 15, 2026

andrewserong commented on Jun 15, 2026

ramonjd commented on Jun 15, 2026

talldan commented on Jun 15, 2026

talldan commented on Jun 15, 2026

CookieDarb commented on Jun 15, 2026

webmandesign commented on Jun 15, 2026

webmandesign commented on Jun 15, 2026

webmandesign commented on Jun 15, 2026

webmandesign commented on Jun 15, 2026

webmandesign commented on Jun 15, 2026

talldan commented on Jun 16, 2026

webmandesign commented on Jun 16, 2026

andrewserong commented on Jun 17, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions