Template Parts: name displayed inconsistent in UI about gutenberg

[simom]

Hi @colorful-tones, thank you for the suggestion.
I've updated the title and prioritized the bug in the ticket.

Regarding your last observation, do you have a specific ticket to refer to in order to discover more about how the template parts will be handled in the future?

[colorful-tones]

My GitHub searching is not all that great today, but here is one issue to maybe take a peak at and many other links in it to point in your further direction around Template Parts: #55595

[annezazu]

Adding this to the polish board as these sorts of inconsistencies add up and this would be a good one to rectify. For now, some work is underway to remove the Details view (what's seen in the first 5 seconds) to consolidate it with the Inspector (what's shown after 5 seconds): #59689 This could be a part of that work potentially cc @jameskoster

[simom]

Hi @colorful-tones, thank you for addressing this ticket.
I noticed you removed the "Bug" tag.
Does that mean the "highlighting a specific template part, the name shown is almost always incorrect" should not be considered an issue?

[colorful-tones]

I noticed you removed the "Bug" tag.
Does that mean the "highlighting a specific template part, the name shown is almost always incorrect" should not be considered an issue?

Thanks for clarifying. I've reassigned Bug. I would encourage updating the title for discoverability.

Maybe: "Template Parts: name displayed inconsistent in UI"

Ultimately, I think that Template Parts will be handled differently, but good to report this. Thanks!

[jameskoster]

We need to decide whether this menu is about highlighting areas, or specific template parts.

The former would be similar to the 'Content' panel we find when editing pages in the site editor:

If that's the way we want to go, then arguably only header/footer template parts should be listed since others do not relate to any specific area. That might be the simplest path forward here.

But it may be worth revisiting this particular UI. Is it adding value compared to List View?

[simom]

Correct me if I'm wrong, but I believe that "areas" are user-defined (via PHP and theme.json) logical placements for matching name template parts. Areas must be associated with an area-tag, which is a valid block-level HTML sectioning element (even if WooCommerce defines a mini-cart area-tag).

Areas should carry a stronger significance compared to template parts, as I perceive them to be "required" for the specific template.

Leaving only the header and footer is not particularly helpful. It would be interesting to have a representation of the higher-level structure, where you can see the header, the content (identified as the first high-level block), followed by theme-defined areas, optional template parts, and footer.

This could help users in understanding the elements' interaction, especially since the "list view" cannot be opened by default, and the right sidebar is the first thing a user sees.

I'm not sure if this makes sense, but I'd be happy to discuss it further since I find editing the template crucial yet also the most disorienting.

[jameskoster]

Good insights, I agree with a lot of the thinking.

Currently all template parts are assigned to an area, but the "General" category is kind of meaningless in terms of semantics... As I mentioned in the previous comment, a first step here could be stripping "General" template parts from this list, or at least separating them from header/footer, and using the correct names as labels rather than the unhelpful "General", e.g.:

I agree with you that only header/footer is a bit lacklustre. It might be interesting to expand the areas concept a little so that it captures things like:

• The "Content" - as you suggested
• The Title (either post/page title, or archive title)
• The main Query Loop in archive templates
• Comments Loop / Comments Form in single templates
• Navigation / Pagination
• ...more?

[simom]

The separation of "other template parts" seems like a good idea for all those templates that are instantiated only within the template being edited.

However, the question of "areas" defined by the theme remains open, because given the explanation provided in this article (https://developer.wordpress.org/news/2023/06/16/upgrading-the-site-editing-experience-with-custom-template-part-areas/), I would expect to find them in the "areas" group, where you have placed header and footer.
Is this approach still considered valid, or with the new changes you are making, will it no longer be recommended?

The idea of having "title," "content," etc. is okay only if these are template parts or areas; otherwise, I'm not sure it's right to include them under "areas."
My proposal was related to the higher-level block, but I'm not sure how to define it well, because referring to "content" may not always be correct.

[jameskoster]

The separation of "other template parts" seems like a good idea for all those templates that are instantiated only within the template being edited.

That is the purpose of the areas UI.

It sounds like you're suggesting a repurpose so that all registered areas are listed, regardless of whether the template you're editing includes blocks assigned to those areas or not? E.g. if there's no header in the template you're editing for some reason, you'd still see "Header" in the "Areas" list?

I'm not quite picturing how that would work... what would happen on click given there's nothing to select on the canvas? Perhaps in that scenario the button becomes an "Add" affordance?

This might work for some template parts, but others (like the Woo example you mentioned) might be a bit strange... it wouldn't be helpful to see a "Add a mini cart" button for all templates given that's something you generally only add to a header/footer/navigation menu.

because referring to "content" may not always be correct.

This is why I suggest assigning a 'content' area to the Content block – because we can guarantee the semantic purpose (and contents) of that block.

[simom]

It sounds like you're suggesting a repurpose so that all registered areas are listed

I am referring to what was explained in the previously linked article, which can be better seen in this image. 'Sidebar' is an area registered by the theme and has an associated template part in that specific template, and therefore it is displayed in the list of 'areas.'

But if I create a template part while I am editing the page template, it is fine for it to be listed under "other template parts".

what would happen on click given there's nothing to select on the canvas?

The idea of "add a ..." could be interesting because it could hook into the pattern inserter by pre-filtering a specific category. Clearly, the observation you made about WooCommerce is correct, but it would be worth asking whether they are taking the wrong approach in this case, especially considering the improper use of the tag.