Style changes made to template parts are only applied to one page

[carolinan]

During a user testing session on April 9, following the FSE outreach program testing call #4, users worked with the header template part in the site editor.

Several users described that when they changed the colors of the header (template part) and saved, the change was only visible on the page they had been working on (the index).

They expected the changes to be applied to all pages where this specific header (template part) was used.

---

Currently, only the content of a template part is update for all pages, not the styles.

[justintadlock]

This is a problem I've run into in recent days too. In building a block theme's header.html, the template part call automatically adds a wrapper <div>. So, to avoid divitis, I removed the wrapper <header> in my header.html and changed the tagName value to header in my template-part call.

<!-- wp:template-part {"slug":"header", "tagName":"header", "backgroundColor":"gray-200"} /-->

This also meant applying my background color to this same block. This quickly becomes problematic from a theme design perspective because any time I make a change to this block I also need to change it in every single template that uses it.

I thought about just living with the extra <div> and switching back to putting the important bits in header.html. However, this results in similar issues when approaching it as a user and wanting to make changes.

Personally, I would not allow template parts to have markup, settings, etc. Those should be done in the part files themselves on the block level.

[carolinan]

I also ended up removing the styling from the template part call and place it in the template part file.
Not only because of this, but because the user can then delete the content of the template part and add a pattern, rather than having to delete the template part and try to replace it with a new one.

The site header needs to be a <header> element, having an extra wrapper is still preferable to me over allowing every block to change the element to a <header> with user facing controls.

[annezazu]

This came up in the seventh call for testing for the FSE Outreach program as well and seems important to clarify in time:

When you’re creating a new template, for each existing template part that you insert, you have to remember to set the same attributes for the template part as used in other templates. Attributes that will need setting include the Width and Colours

[Addison-Stavlo]

Just noticing this issue and hoping I can add some extra clarification on what is going on.

When you add attributes to the template part block:
<!-- wp:template-part {"slug":"header", "tagName":"header", "backgroundColor":"gray-200"} /-->

You are adding attributes to the block that references the template part, not the template part itself. So when a background color is added at this level, it makes sense that it only effects that block. Similarly consider the slug attribute on this block, it tells this specific block which template part it needs to display - it does not change or effect any actual template part entities - as is the same for all the other attributes added here. This is how the block attributes at this level are expected to behave.

RE: the in-editor confusion with editing and saving boils down to the same as above. When you change the background on your template part block, its just like changing the background on any other block. The block belongs to the parent post (generally the template in this case), thus changing settings on the block prompts saving the parent only. The template part block does not belong to the template part, its just 'another block' that is used to display whatever template part it is told to, thus edits to that block's attributes do not prompt saving an actual template part. Only edits to its internal contents (the actual template part contents) trigger saving the template part itself.

I also ended up removing the styling from the template part call and place it in the template part file.

This 100% makes sense. If you want the styles shown across all instances of a template part, they should be part of the template part entity and not part of the block calling it.

and changed the tagName value to header in my template-part call.

I think at this point that should be unnecessary (although doesn't hurt). If a template part is created for a specific area like header (or defined this way in the theme.json - example), then its default tag when rendered should automatically be a header. The tagName on the block gives the user the power to override this default functionality on a per-block basis if necessary.

---

Now, hopefully that all makes sense from a technical standpoint. However, it doesn't resolve the in-editor confusion new users will face when selecting their header and updating the template part block's styles to only have them change on that specific template.

Im not sure the best way to clean this behavior up for users. One suggestion would be to have the attributes of the template part block sync to a sort of invisible group wrapper of the template part it references. This however, limits control on the other end of the spectrum where a user may want to display their template part slightly differently (alignment, background-color, etc.) on different templates. 🤔

[jameskoster]

I agree that the current UX feels very confusing. I think the problem is that there's no distinction between the types of changes you're able to make. For example re-arranging the blocks in the header is a global change, while changing the overall background color is local. But the user is given with no clear indication as to why one change is local and the other global.

It would be interesting to see some design explorations that seek to clarify things here. Perhaps you should only be able to make local changes while editing a template, and to make a global change you need to edit the template part in isolation? Or perhaps the local overrides (powerful as they are) are simply unnecessary at this stage, and we should make all edits global?

Matters are made worse by the fact that you're currently unable to configure things like the color settings when performing an isolated edit (#30641).

[Addison-Stavlo]

Matters are made worse by the fact that you're currently unable to configure things like the color settings when performing an isolated edit (#30641).

At this point I would consider that a good thing, as the only color settings that currently exist are 'local' and having local settings in isolated mode would be even more confusing and inconsistent. But in general, that is the source of the issue... we currently only have 'local' / block settings for these styles. We cant set a color or alignment setting for our template part post just the same as we cannot set a color or alignment setting for our page, post, or template postTypes - and I don't think any mechanism for that currently exists. So to change the styles around everything in isolated mode would require everything to be wrapped in a group block, and editing the styles to that group block directly.

So in general, posts arent currently set up to handle this. If we do want to make an exception for template part posts and find a way to set style settings directly to that post, we need to figure out a good way to handle that from the technical side as well. Whether it is saving these styles as part of post meta, taxonomy, as an 'invisible' group block we hide behind the scenes, or something else.

[jameskoster]

I think we should prioritise getting the UX right first and foremost, and based on the feedback we've gotten so far we're not there yet. The expectation seems to be that if you change the properties of a template part whilst editing a template, those changes would be applied globally rather than locally.

I'm inclined to say that we should treat all template part changes as global for now, whether they are made whilst editing a template, or editing the template part in isolation.

To make working with a template part 'feel' more global, we might consider bringing the save button pattern for Reusable Blocks to Template Parts as well.

A more extreme alternative would be to say that you cannot edit a Template Part at all whilst editing a template, and that you have to engage the isolated view to make changes. If that's easier, it may be worth trying.

Either way, we'd need to add color/dimension options to the isolated view as well 🙊

The overrides are a powerful feature, but need careful design consideration to make them feel intuitive. In the mean time folks can always just create alternative template parts to achieve a similar result, like we've done in Twenty Twenty-two.

[Addison-Stavlo]

I think we should prioritise getting the UX right first and foremost, and based on the feedback we've gotten so far we're not there yet. The expectation seems to be that if you change the properties of a template part whilst editing a template, those changes would be applied globally rather than locally.

I agree and that direction does seem like the logical way to be moving. My point is that we cannot ship this proposed UX without having the infrastructure to handle it. So while we want "UX first", we also need to make technical decisions that will make that UX possible - how/where these styles are saved on the code side, how they are represented initially from the theme code side, and how the inconsistencies that are created regarding standard block attribute and markup behavior are handled.

[jameskoster]

Here are some design options for us to discuss.

To recap, here's the current, confusing experience:

current.mp4

Note that the block re-arrangement is a global change, and visible when editing the template part in isolation, but the background color change is not. Also note that it's not possible to set the background color whilst editing the template part.

Option 1 – All changes are global

One approach would be to say that regardless of where you edit a template part, the changes are applied globally. This probably feels most intuitive, but means we lose the over-ride functionality.

globally-synced.mp4

Option 2 – Template parts can only be edited in isolation

With this approach it's not possible to edit the template part contents / style at all whilst editing a template, you can only move it around, replace it, etc.

This perhaps helps clarify that things like headers are global entities in their own right, and also creates a space for us to explore overrides in the future. The drawback with this approach is that you lose direct manipulation, but perhaps a double-click action could take you directly to the isolated editing view?

option2.mp4

Any thoughts on these approaches? Or any other options we could explore?

[Addison-Stavlo]

For clarity, is Option 2 an extension on Option 1? That is, with option 2 all changes are global as well?

If im interpreting that right, Option 1 seems to make sense to explore and will also enable option 2 down the road if we decide that extra restriction is necessary.

but means we lose the over-ride functionality.

I think there will still be ways to accomplish the same behavior (Ex - leaving template part's styles/settings general, and wrapping the template part blocks inside a group block on the template, setting those styles/settings on the group blocks themselves - or just creating other variations of the same template part with different styles). It would be a little more odd, but it seems like an acceptable tradeoff since the use case for overrides seems a lot less common than for consistent template part styles/settings.

[jameskoster]

That is, with option 2 all changes are global as well?

Yeah that's right. Any changes you make whilst editing a template part in isolation would be applied globally.

I don't have strong feelings personally about either concept, but would probably lean slightly towards option 2 since it minimises the template part editing UX whilst editing a template. That accomplishes two things:

1. Helps clarify that template parts are unique global entities, and not directly related to any specific template.
2. Gives us more flexibility to explore design options for true overrides in the future, in ways that wont disrupt any existing flows.

It may even be worth trying both?

[Addison-Stavlo]

At this point in time, my main opposition to option 2 is related to how we currently enable the isolated mode in the Site Editor. In the current limited FSE beta on dotcom, the navigation sidebar itself is hidden due to user confusion related to nav sidebar behavior such as opening to nested levels, lack of an editor close button at those levels, conflicts caused by assumptions made when opening to those levels, and simply that exposing the template hierarchy at a prominent level to new users with simple goals ends up as a confusion point. I think it would be good to update the nav sidebar itself or how we get into isolated mode within the Site Editor before we restrict things to only being editable in that mode.

We do also have the isolated mode in the post editor (Appearance -> Template Parts), but depending on that forces a very fragmented experience as well. Imagine trying to 'try out' and customize a couple template part options for a template, this would require a lot of backing-out and reloading different editors just to try out a couple different things and view them in their used context.

[critterverse]

Hey @jameskoster, either of these directions would be a huge improvement on the current experience.

Option 1 seems more straightforward and is probably what I'm expecting to happen as a user.

Option 2 seems a bit more complex. Conceptually-speaking, when I think about how the isolated view is currently constructed with only the inner blocks, it seems like Color and other options for the outer container would be document-level settings vs. block settings.

If the outer Template part container did become editable within the isolated view, maybe we could consider something similar to the way Widget Areas work — top-level areas like "Footer" are container blocks that appear in the List view and are selectable on the canvas but they are sort of locked down with limited functionality (no toolbar and you can't access the ellipses menu to Copy, Move, Remove, etc).

[jameskoster]

At this point in time, my main opposition to option 2 is related to how we currently enable the isolated mode in the Site Editor.

That's a fair point, though I hope the double-click pattern would remedy that. It's hard to say for sure without trying it.

I think it would be good to update the nav sidebar itself

The nav sidebar is actually being removed for 5.9 (#36194). So to access template part focus mode you can:

• Go through Appearance > Template Parts (although this doesn't currently work 🙈 – Update Appearance > Template Parts #36205).
• Use the ellipsis menu on the block toolbar while editing a template.
• Double-click (if we went with option 2).

it seems like Color and other options for the outer container would be document-level settings vs. block settings

Perhaps I'm mis-interpreting, but isn't this how it works now? 😬 You set the background color for the header while editing the document the header is inserted into. But that only updates the document, and the header is not changed.

If the outer Template part container did become editable within the isolated view

I think we may need to do this regardless. Because otherwise if you wanted to change the background color of your header, you'd need to go and do that in every single template, which kind of goes against the idea of the header being a discrete global entity. I suppose you could "hack" it by wrapping the contents of the header in a group, but obviously that adds weight to the UX, and means you wouldn't be able to achieve per-template overrides.

[critterverse]

Perhaps I'm mis-interpreting, but isn't this how it works now? 😬 You set the background color for the header while editing the document the header is inserted into. But that only updates the document, and the header is not changed.

I mean that, conceptually, these options feel like document-level settings for the Template Part post type (based on the current constuction of the isolated view where the container is not included/selectable on the canvas):

I keep saying conceptually because this doesn't really fit in with our current architecture of color controls UI 😅

If the outer Template part container did become editable within the isolated view — I think we may need to do this regardless. Because otherwise if you wanted to change the background color of your header, you'd need to go and do that in every single template

I might be oversimplifying but can't you also do this in Global Styles / Blocks / Template Part / Colors? I suppose that this would work better if we could break the GS block controls down further into Template Part areas like Header, etc (but that still might not be as granular as we need it to be).

[jameskoster]

I mean that, conceptually, these options feel like document-level settings for the Template Part post type (based on the current constuction of the isolated view where the container is not included/selectable on the canvas)

Oh jeez, only now do I see I uploaded the wrong videos. You're correct of course, those should be in the 'document' tab. I'll fix the videos.

I might be oversimplifying but can't you also do this in Global Styles / Blocks / Template Part / Colors? I suppose that this would work better if we could break the GS block controls down further into Template Part areas like Header, etc (but that still might not be as granular as we need it to be).

You can, but those are still applied at the template level. Forcing folks into the depths of global styles to change the background of their header doesn't seem very intuitive. It's also worth noting that setting the background color for a template part in global styles would apply that color to all template parts. So if you had two headers and wanted a different color set for one you'd still need to do that on the template part itself.

[carolinan]

If styling options for the template part were removed and the block worked more like a container only,
the colors etc would be set by the content, and that would solve the problem.

Without buy-in from theme developers, I think that option is too late and too drastic, even if the template part block is still experimental.

[jameskoster]

The other option – as mentioned above – would be to remove all display settings from the template part (both the block and the document). Then if you want to add a background color / padding you'd have to wrap the contents of the template part in a group and apply your styles there.

This means adding extra weight to the template part contents, but it would circumvent the technical issues pointed out by @Addison-Stavlo.

It also means you lose the per-template overrides, but the more I think about that the more it seems to be a good thing for the overall UX. If you want to do something unique with a template part in one template, the uniqueness should be applied to the block(s) that contain the template part, not the template part itself. Or you should just use a different template part altogether. Otherwise the heuristic that template parts are discrete global entities is eroded.

For the sake of completeness, here's how that option plays out:

option3.mp4

Overall this seems like the simplest path forwards, and is most aligned with how template parts work in classic themes where you cannot change the properties of a single template part in a specific template. It also satisfies @justintadlock's suggestion above:

Personally, I would not allow template parts to have markup, settings, etc. Those should be done in the part files themselves on the block level.

[carolinan]

How and should it be kept backwards compatible for the existing themes?

The impact on Twenty Twenty-Two would not be that big, the header and footer parts are mainly patterns.

[Addison-Stavlo]

I think Jay's most recent proposal does make a lot of sense. My initial concern here was how users are able to recognize/select that internal group block, but the list view makes that very simple. Thinking about it more, knowing about and using the list view seems vital for anyone using the site editor - so it seems reasonable that we depend on this feature to make this flow simple (sanity check?). However, changing styles on a header may also be one of the first things a user may try to do with their new site so it seems important to note that we need to surface the list view very early in any nux/tutorial initiative.

It also means you lose the per-template overrides

I also don't think this is a huge issue. For things like colors, these aren't really overrides anyways since any specific settings on internal blocks will override that of those on external blocks - so the template part block's colors only really 'override' (if you can call it that) when the internal contents don't have any specific style set in the first place. For the tagName, I don't think this is a huge issue either. For non-general template parts it seems highly unlikely that a header shouldn't have a <header> tag, etc., and if it does it probably warrants a separate template part. For general template parts the default wrapper is a <div>, and a semantic element tagName can be chosen and saved on the aforementioned group block.

One issue here is that relying on that extra group block adds an extra unnecessary element on the html side of things which would make @justintadlock 's quest "to avoid divitis" a bit more difficult.

How and should it be kept backwards compatible for the existing themes?

Thanks for mentioning this @carolinan, as it seems vastly important to consider no matter which direction this goes. Im not immediately sure about the how, but I definitely think we should try to keep backwards compatibility the best we can despite things still being labeled "beta".

[jameskoster]

I don't think there's anything we can do to programatically address any issues in themes that arise from this change. That said, theme authors will still be able to achieve all the same results as before, mostly with the addition of a group block in their template parts as described above.

The worst case scenario is theme authors that are applying different background colors / padding etc to the same template part in different templates. In those cases they would need to create new template parts specifically for those templates, or add wrappers around the template parts.