Rethink how the template part work and persist its properties

[youknowriad]

The template part as written today supports a number of properties:

• tagName to choose the wrapper tag: header, footer, section, div...
• some styling attributes: color...

The idea was that template parts should have similar configuration options as the group block to be able to use them properly for headers, footers, sidebars...

The problem though is that these properties are saved as regular block attributes in the comment something like:

<-- wp:template-part { "tagName": "footer", "postId":10  }  /--> 

which means they are not saved on the template part itself but on the "caller" or "template" making use of the template part. It means these semantics do not persist across the usage of the same template part, and this kind of defeats their purpose.

Potential solution

• Make the template part block work like an empty wrapper (like a reusable block) without any customization properties
• On the UI level, when creating new template parts... encourage the addition of a group block at the root level of all template parts.

cc @noahtallen @vindl @mtias

[mtias]

I think conceptually it makes sense to attach properties to the template part, but perhaps there's a way to make the Group be a controlled block (always the first element) even if its properties can be set from the template part UI (they are saved instead in the Group). Would that make sense?

[noahtallen]

I do think the challenge with nested group blocks is just that navigating nested blocks is not an ideal experience (in my opinion), so I personally prefer to avoid requiring it for common use cases. (Especially because the nested block inserters cause the UI to jump around)

It means these semantics do not persist across the usage of the same template part, and this kind of defeats their purpose.

One of the arguments from @Addison-Stavlo when we discussed this last was that it might be more practical to have the attributes be specific to the entity than to all template parts. Copying my comment from a different issue:

I'm on board with just leaving it as block attributes at the template level. The two things that persuaded me:

• It's a lot easier to put a group block inside a template part and have it apply to all template parts than it is to put a group block outside of every template part.
• None of the possible solutions to the problem seem to work in a clean way with nice API. On the one hand, we would be trying to directly block attributes into post meta of a different post, which would be pretty non-standard, and on the other hand, we would be trying to merge two template part block attributes with each other.

(from #22034 (comment))

I do like the idea of allowing those attributes to be global, but I'm just not sure how to make that happen, since the template part block itself is not ever global by itself

but perhaps there's a way to make the Group be a controlled block

would this mean that the group block is basically "transparent" in the block editor?

[Addison-Stavlo]

and this kind of defeats their purpose.

I don't think it entirely defeats their purpose. It gives settings that can be applied specifically on that template. Thus the same template part could be used on multiple templates with minor style differences (color variations, etc.). I discussed an example of how this might look in practice here: #22034 (comment):

Consider the following example - A user wants to create a website to support bi-partisan political blogging. They want to use the same header across all pages of their site, but want different variations of the background color:

• Homepage / Info Pages / all-posts feed - They want the background of the header to be a linear gradient from blue to red.
• Pages that list liberal tagged posts - They want the header to be blue.
• Pages that list conservative tagged posts - They want the header to be red.
• Pages that list centerist tagged posts - They want the header to be purple.

If these settings are on the block attribute level, all these pages need is a different template that references the same template part. If these settings persist across the entity itself, not only would they need a different template for every situation, but a different Template Part as well!

Looking back at the semantic tag, this makes sense to be applied at the Template level as well. As the template is what determines where that template part is placed and what it is being used for in that specific circumstance. If a template supplies a template part block at the top of the template and lists its semantic tag as a header, its semantic tag should probably still be a header even if the user switches the entity it references to a template part that was initially intended to be a footer.

[youknowriad]

The ship has sailed here. I'm closing for now.