changing Template Part taxonomy proposal - add 'type', rebrand 'theme'

[Addison-Stavlo]

As the site editor experiment progresses and more design iterations and discussions are evolving, it may be a good time to discuss appropriately changing the taxonomy of template parts.

Adding a 'type' attribute

Currently, a Template Part is defined by 3 main attributes: id, slug, and theme.

My first proposal is to add a ‘type’ (or similarly named) attribute. This would be more controlled to fall under a set of pre-defined categories: “Header”, “Footer”, “Sidebar”, “Nav”, “Misc”, etc...

This will help solve 2 problems:

Semantic HTML support

This would give us a meaningful data field that can be used to decide between semantic HTML tags. The “Header” type could be wrapped in a <header > element, “Footer” for <footer >, others to <nav >, <section >, and at worse case fallback to the standard <div>.

Organizational purposes for browsing and replacing template parts.

Recently on #22612 I explored adding Template Parts via the inserter. Since all we really have at the moment is “slug” and “theme”, we are limited in how we can group template parts. This limits us to grouping by “theme”, which means template parts are grouped by where they came from as opposed to what they are intended to be used for. This does not seem optimal.

Recent design iterations also show things such as grouping by ‘type’ (https://github.com/WordPress/gutenberg/issues/21218#issuecomment-634707751). Without adding a ‘type’ attribute, searching by intended use would rely on the ‘slug’ being appropriately named (an assumption that I don’t think is reasonable to expect in all cases).

Similarly, the flow for replacing a template part would be simplified. If a user wanted to replace their header, they could be guided towards the other options for “Header”. As opposed to searching through themes and slugs and potentially guessing on intended use of the Template Parts that are listed.

Re-branding 'theme'

My second proposal may be a bit less of an immediate concern, but is still something to consider as we move forward. Instead of 'theme', consider another term such as ‘collection’.

While ‘theme’ makes sense when a template part is supplied by a theme, it doesn’t make as much sense when it is added by a user for their site. It is not part of a particular theme, and can be used with different themes. I do feel that asking for the name of a ‘collection’ for it to belong to does make more sense, even though it is a very subtle difference.

Template parts supplied by themes would have the old ‘theme’ attribute as their ‘collection’ name. Template parts supplied by users could default to the site name, or allow them to enter some value for a 'collection' name. This could then potentially be utilized and expanded upon as a method of importing/exporting collections of template parts that are theme agnostic.

'Collection' makes a bit more sense to me as the user facing term here. So even if we don't end up changing the name of the 'theme' attribute, we may want to consider using a different term in the editor.

---

Im wondering what other peoples' ideas are. @epiqueras @vindl @noahtallen @ockham - do you have any thoughts on this? Does this make sense, might there be any issues/blockers I'm overlooking, do you have any alternative suggestions/solutions in mind?

[noahtallen]

Add a type attribute

I like this idea. Maybe it would be something like a category taxonomy for the template part CPT?

It is not part of a particular theme, and can be used with different themes.

This is a great point. I don't think we should limit ourselves to thinking of template parts as strict children of a single theme when we don't have to.

This kinda relates to the auto-draft nature of templates & template parts supplied by themes. It's confusing because the fact that the template part is "unsaved" seems to indicate that it won't show up on the front end or that the changes have not been persisted, which isn't true.

[epiqueras]

Adding a 'type' attribute

Yes

Re-branding 'theme'

This isn't necessary as it's something a user should never see. The value is chosen for them based on the current context. We could do something like themeName + '/custom', or even let them create additional groupings with themeName + '/' + groupName.

[noahtallen]

I think the problem is that if you switch themes, you no longer have access to the template parts created under the old theme, right? That's not very flexible, IMO, and it's essentially an arbitrary distinction. It wouldn't be hard to be flexible here because a template part doesn't actually rely on a theme for anything (at the moment anyways)

[Addison-Stavlo]

This isn't necessary as it's something a user should never see. The value is chosen for them based on the current context. We could do something like themeName + '/custom', or even let them create additional groupings with themeName + '/' + groupName.

My concern here is that a user creating a template part for their site probably won't expect it to be associated with whatever theme was applied at the time of creation. Template Parts can be completely independent of themes, so forcing them to be associated with one seems odd.

[epiqueras]

I think the problem is that if you switch themes, you no longer have access to the template parts created under the old theme, right? That's not very flexible, IMO, and it's essentially an arbitrary distinction. It wouldn't be hard to be flexible here because a template part doesn't actually rely on a theme for anything (at the moment anyways)

You still have them if you've saved them.

My concern here is that a user creating a template part for their site probably won't expect it to be associated with whatever theme was applied at the time of creation.

We don't have to do that. I was just giving examples.

I think the value should be a hardcoded custom identifier that will never clash with a theme name.

The UI can show the custom template parts and then the template parts provided by themes in their respective theme groups.

[Addison-Stavlo]

I think the value should be a hardcoded custom identifier that will never clash with a theme name.

Ok, that makes sense to me if I'm understanding this correctly. In that case it wouldn't be some input field that the user would have to concern themselves with. When a user creates a template part in the editor, we could populate the 'theme' attribute with something like "mySite" or "mySite/" + something else if necessary. That would be nice, it would definitely feel better to only require 1 input (for 'slug') on creation.

[noahtallen]

we could populate the 'theme' attribute with something like "mySite" or "mySite/" + something else if necessary

it could even be blank to represent that it could be used for any theme

[epiqueras]

Yeah, and we probably want to surface slug as "Name" in the UI.

[noahtallen]

Yeah, and we probably want to surface slug as "Name" in the UI.

Makes sense to me. I feel like we should generate a unique ID other than the name in this case

[epiqueras]

They have their post ID.

[noahtallen]

What are the current action items for this?

[Addison-Stavlo]

I think the 'type' was a generally accepted idea to move forward with?

Although thinking more it would probably be preferable to have this 'type' as post meta and not as an actual block attribute? 🤔

[noahtallen]

🤔 Yeah, I think that makes sense in general. Do we need to be able to support it in the block template part HTML files?

[Addison-Stavlo]

Do we need to be able to support it in the block template part HTML files?

Ah yeah, definitely! 🤔 Im not sure the best way to handle it. Maybe both an attribute and post meta? Allow it to be initialized via an attribute from the HTML files, save it as post meta so other template part blocks referencing that template part entity are able to reference the proper value, and keep that attribute in sync with the saved post meta value? It would also mean that if we changed it on template A, then template B would load in the dirty state as the attribute would update to reflect the new post meta... but maybe we could set up a behind the scenes auto-save for that kind of case.

That all seems a bit convoluted but should work... but perhaps there is a better way? Also we will need a similar solution if we want template part block styles sync'd across all uses of the same entity.

[vindl]

I think the 'type' was a generally accepted idea to move forward with?

I'm in favor of adding this and it will definitely be required to implement some of the existing designs for templates part grouping etc. I think we should also come up with a list of canonical types that core defines, and allow it to be extended.

Although thinking more it would probably be preferable to have this 'type' as post meta and not as an actual block attribute? 🤔

I thought we'll be adding this is a new taxonomy for template parts? Also there were some performance concerns raised around using post meta quires recently: https://github.com/WordPress/gutenberg/issues/24377

[noahtallen]

I'm not super familiar with taxonomies, how does that fit in?? We're running into a similar scenario with certain block attributes which need to be applied to the template part block (which belongs to the parent), but those attributes need to be saved to the template part CPT itself so they are available on all instances of a template part block referencing the same template part.

[Addison-Stavlo]

I'm not super familiar with taxonomies, how does that fit in??

I assume that means adding tags or categories to the template part post? But that seems a bit odd as in you can keep adding them, where postMeta is more of a key/value situation which seems more fitting since we only ever want 1 value for the semanticTag at a time. 🤔

[Addison-Stavlo]

We're running into a similar scenario with certain block attributes which need to be applied to the template part block (which belongs to the parent), but those attributes need to be saved to the template part CPT itself so they are available on all instances of a template part block referencing the same template part.

Thinking about this more, there can be a solid argument for just using the block attributes for this kind of thing. No, it will not persist when you insert that template part on a new template, but maybe the template should have that control in the first place.

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.

Now, we could ALSO use taxonomy to aid in the searching of template parts based on what they may have been intended for.. but in terms of applying specific wrapper styles and semantic tags it may make the most sense to do it at the block level as opposed to restricting the entity itself.

[noahtallen]

That is a really interesting line of thought :thinking:

Could you cross post some of that to #22034??

[Addison-Stavlo]

I think it is safe to close this?

• We added the support for the block to handle semantic tags.
• There doesn't seem to be much sense to rebranding theme.

There could be a use for adding tags or categories for organizational purposes, but its a bit uncertain at this point in time whether or not this is actually necessary. We can create a new issue for that if this seems necessary in the future.

Feel free to re-open.