Expand the types of templates that can be added in the Site Editor

[jameskoster]

Currently it's possible to add the following Primary templates in the Site Editor:

• Front page
• Single
• Page
• Archive
• Search
• 404
• Index

It's a good start, but the WordPress template hierarchy allows for much more expression. It would be good to explore flows that allow the creation of:

• Custom/general templates Site Editor: Add New - Custom/General template #36860
• Template for a specific post (single-post-$slug)
• Template for a specific page (page-$slug)
• Date template (date)
• Attachment template (attachment)

Author templates

• author
• author-$nicename

Category templates

• category
• category-$slug

Custom post type templates

• single-$post-type
• single-$posttype-$slug
• archive-$posttype

Taxonomy templates

• taxonomy
• taxonomy-$taxonomy
• taxonomy-$taxonomy-$term

Tag templates

• tag
• tag-$slug

---

Tangentially related:

• Ensure that no templates created in these flows are empty (FSE: Pre-populate template with fallback upon creation #42007)

[Otto42]

This would seem to be a necessary item for a viable release.

The very first thing I attempted to do when switching to the new theme and editor was to try to find how to create a Category Archive template. Couldn't find it.

Eventually I worked out that copying archive.html to category.html in twentytwentytwo did the trick, but that is very unintuitive.

Seems like the existing Template Hierarchy should be used for defaults like this, and then expose all/most templates in that hierarchy as selections to be made. If I select "Category" for the template, but there's no category.html, it falls back to archive.html in the hierarchy, and that is my starting point for customization. But the customized template I then create is still the Category template, not the Archive template.

[karmatosed]

I really like the idea of expanding, but I wonder if that then needs easier ordering or something that doesn't surface everything at the same level? I worry a little about too long a list for example and problems even finding things. Something to explore!

[jameskoster]

For sure, this is not a trivial project!

I'm also wondering if we'll see some overlap with #36667. If / when it is possible to work on a specific post category in the site editor, it seems plausible that we'd offer a way to spawn a new template for that category as a part of the overall flow.

[jameskoster]

The very first thing I attempted to do when switching to the new theme and editor was to try to find how to create a Category Archive template.

Adding the secondary category template as an option for folks to create would obviously be a simple change we could make any time.

Seems like the existing Template Hierarchy should be used for defaults like this, and then expose all/most templates in that hierarchy as selections to be made. If I select "Category" for the template, but there's no category.html, it falls back to archive.html in the hierarchy, and that is my starting point for customization.

I think what you're describing is being worked on here.

[SJGraboski]

Saw that this issue mentioned the possibility of creating custom post type templates in the Site Editor. Like several other web developers, I help manage a WP Multisite implementation. If the Site Editor allowed devs like us to make CPT templates, it would make for a profound improvement to our experience with WordPress.

For starters, we could remove several child themes that exist only to provide our departments with CPT layouts, archives, and search pages. The only files we would need are the plugins that define the CPTs. Who wouldn't love a less complicated repo?

The advantages stretch past the dev team. In theory, we could offer our editors the ability to edit these CPT templates, no coding required. This would enable our non-programming co-workers to change template layouts without relying on our assistance. The editors get more power over their sites, and the developers gain more hours of productivity.

tl;dr, custom post type template creation through FSE would lend editors more freedom to change the site, while reducing the number of theme files developers would need to maintain.

[jameskoster]

Custom Post Type templates are an interesting one, because it brings in to question the creation of the CPTs themselves.

Creating templates for existing CPTs feels like table stakes, but also a fairly developer oriented solution because it requires the CPT to be registered in the first place.

Thinking further along the road... I wonder if there's a world where the Site Editor could enable users to add modules like "Portfolio" or "Testimonials". These modules could register the CPT and create all the necessary templates in a single flow. This would eliminate both the child theme and the plugin dependency from your example. With block patterns and other tools available to us we could potentially make this quite a compelling experience.

[aurooba]

@jameskoster I enjoy the idea that core might provide a UI for CPT creation, sometimes I want a CPT, but don't want to have to pull out the code editor to do it, especially if it's going to have pretty much the same capabilities as a post.

I'd also like to mention that as the ability to make more templates (and variations) comes into play, the ability to duplicate a customized template (and in the flow of doing so, assign the customizations to a different template) will be very very useful – I made an issue for that recently, #38192 (edit: I've closed the issue and added my comments to another existing issue #36665).

[jameskoster]

I spent some time exploring how we might expand the existing UI to accomodate other template types. There are a few different ways to organise things here, particularly around how we present singular / archive templates, and dynamic / static templates as well.

What I felt worked well was separating templates by their specificity. That is to say: templates that serve a static purpose (404, front-page, *-$slug etc) are grouped together, and templates with a dynamic purpose appear beneath:

It is important to note that while the list looks quite daunting, it is unlikely an end user would ever see it in its entirety like this because any template supplied by the theme would be omitted.

This arrangement elevates the prominence of creating templates for a specific context – which I think is likely to be quite a popular flow – while still making it very simple to add common templates like page. Here's a video demonstrating how the "Specific template" menu item drills into a search form where I can find entity capable of entertaining its own template:

template1.mp4

Note that those blue boxes that appear on hover are template previews. Once #37258 lands I hope it will be possible to display a reasonable preview.

The "Advanced" section at the bottom of the menu would contain templates that the average user is unlikely to use all that often, e.g. taxonomy. It may be prudent to put other less commonly used templates (like date) in here as well, and consider a different name for the section.

Another thing I considered was splitting the dynamic section by singular / archive like so:

But in the end it felt unnecessary.

[anelllya]

What I don't quite understand is the need to perform a SEARCH once you want to go to a specific template. A search always implies that you know the name or that you know what you are looking for.
I would show a list of probably the most used or last created templates with possibly a filter if users have too many.

Other than that I find it a great idea to sort the templates that way.

[paaljoachim]

Hey James! This is a very nice exploration!

I find it helpful to separate templates into static and dynamic as in your suggestion.
Clicking for instance "Specific template" and getting a search form. I would become lost not knowing what to search for. As I do not get a hint of options to choose from. Here I would need some additional guidance on how to proceed after selecting "Specific template".

Having static and likely "most used" dynamic templates available is helpful. A see additional template choices - see additional templates > link to open another list can also be helpful.

Kinda like this:
Static template 1
Static template 2
Static template 3
-- separater --
Dynamic template 1
Dynamic template 2
Dynamic template 3
Dynamic template 4
Dynamic template 5
Dynamic template 6
-- separater
See additional templates > (opens the Additional templates list)

Btw previewing various templates would be nice.

[jameskoster]

Thanks for the excellent feedback @anelllya @paaljoachim.

I think the language I used on the "Specific template" drilldown has lead to some confusion. To clarify: the purpose of that part of the UI is to allow folks to create unique templates that will automatically render for different entries or archives. Things like category-$slug or author-$nicename. So for example: if you wanted your "Recipes" post category to appear a certain way, you could create a specific template just for that category by searching for it. In that sense I think it's unlikely that you'd enter this flow without knowing what you were creating a template for.

All that to say, the problem may be more to do with the wording on that "Specific template" button. I would love to hear suggestions there.

With regards to the search form, maybe we could include a list of recently edited items beneath it, like this:

Another option would be to include drilldowns to browse posts and pages:

But that will become very complicated when you factor in things like page children, tags, categories, dates, authors, and other taxonomies. I think there might end up being too many layers of nesting for it to feel intuitive.

[anelllya]

The first example from the last comment is exactly what I meant before.
So count a vote on it.
And I think that the term "Specific templates" is easy to understand.
Sorry for the multiple editing of the comment - it's my first comment ever in the open WP repo :)

[paaljoachim]

A drill down would hold my hand as I go through unknown territory, but having the chance to strike out on my own would also help. Meaning offer the most common drill down paths but also offer a search as you are showing with the last mockup. "Search for a post, page archive or other kinds of templates" or something like it would say that there are additional template options to choose from.

This way a user would be able to see common paths to know about various options, but a more advanced user would search for specific paths they need to use.

[courtneyr-dev]

Can we include Post Formats as part of the templating? This would help for back compatible uses for sites already containing these post types.

As these are tied to index/blog archive and single post, can these show being templates within the higher levels somehow (envisioning some visuals that look similar to child pages)

[jameskoster]

Good question. Post Formats aren't represented in WordPress' template hierarchy, so are perhaps not a good fit in the context of this issue. Especially as they're a large (and optional) feature in their own right – we want to do them justice!

I'd love to see a way to customise the Post Template block that we have inside Query blocks so that it can entertain different post types and formats, but that's almost certainly a separate endeavour.

[annezazu]

As more templates are added, I wanted to provide a request from the twelfth call for testing for the FSE Outreach Program to add the ability to sort by recently updated, alphabetical, or type. I imagine this isn't a problem today but, in the future with more templates, it would be excellent to sort quickly.

[jameskoster]

@annezazu I think that warrants a dedicated issue 👍

[paaljoachim]

I went ahead and added the issue here: #39307

[getdave]

Merchants would need to completely rebuild the taxonomy template from scratch every time they wanted to create a variation for each product category.

This is currently quite a jarring experience when you create a Category template. When we have the category-$slug.html functionality in the UI it would be ideal if the created template automatically used the block's from it's parent in the template hierarchy.

[mtias]

@getdave that's what #37258 aims for!

[jameskoster]

Here's a couple of design options focussed on the process of creating templates that can be generic or specific. In this case creating category or category-recipes.

Option A

This one builds off the last concept but simplifies the UI down to just a radio list.

category-a.mp4

Option B

This one uses a two step process with more verbose descriptions.

category-b.mp4

[mtias]

Option B looks like a good path to explore. I miss the extra helpful text we had here:

But tailored for what it means to add a template for a specific category slug, in this case.

[ntsekouras]

Option B looks like a good path to explore. I miss the extra helpful text we had here:

I'll start exploring this, but with post types for start. We can always iterate on the POC I'll have soon and I guess the approach taken will be similar for taxonomies, etc..

@mtias you screenshot is a bit different from @jameskoster 's one. Is it more about the missing description?

My first thoughts for postType would be a new menu item (if eligible) that would say Post Type and have two options:

1. The generic one that is single template
2. Select a custom one (that would show the available post types like single-post, single-project, etc...)

[jameskoster]

Is it more about the missing description?

Yes I think so, we can add this in the PR.

My first thoughts for postType would be a new menu item (if eligible) that would say Post Type and have two options:

1. The generic one that is single template
2. Select a custom one (that would show the available post types like single-post, single-project, etc...)

To implement the design above consistently we'd have separate items per post type, and per taxonomy. As an example, if you had 'Products' as a CPT and 'Product categories' as a custom taxonomy then the add template menu would include:

• Single product
• Product archive
• Product category

Clicking "Single product" would ask if you want to add single-product or single-product-$slug using the "Option B" flow. Clicking "Product archive" would create archive-product. Clicking "Product category" would ask if you want to add taxonomy-product_cat or taxonomy-product_cat-$slug, again using the flow in Option B.

[jorgefilipecosta]

Working on author-$nicename.

[jorgefilipecosta]

author-$nicename ready for review at #37407.

[ntsekouras]

All listed items have been merged.

[Mamaduka]

I locked the conversations on this issue. Unfortunately, the last few comments look like spam.