gutenberg
gutenberg copied to clipboard
WordPress
Expand the types of templates that can be added in the Site Editor
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:
- [x] Custom/general templates https://github.com/WordPress/gutenberg/issues/36860
- [x] Template for a specific post (
single-post-$slug) - [x] Template for a specific page (
page-$slug) - [x] Date template (
date) - [x] Attachment template (
attachment)
Author templates
- [x]
author - [x]
author-$nicename
Category templates
- [x]
category - [x]
category-$slug
Custom post type templates
- [x]
single-$post-type - [x]
single-$posttype-$slug - [ ]
archive-$posttype
Taxonomy templates
- [x]
taxonomy - [x]
taxonomy-$taxonomy - [x]
taxonomy-$taxonomy-$term
Tag templates
- [x]
tag - [x]
tag-$slug
Tangentially related:
- [x] Ensure that no templates created in these flows are empty (https://github.com/WordPress/gutenberg/pull/42007)
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.
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!
For sure, this is not a trivial project!
I'm also wondering if we'll see some overlap with https://github.com/WordPress/gutenberg/issues/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.
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.
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.
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.
@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).
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:
https://user-images.githubusercontent.com/846565/152965509-67d1384a-260d-4b2d-bcca-bfcab7ebe1c5.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.
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.
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.
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.
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 :)
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.
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)
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.
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.
I went ahead and added the issue here: https://github.com/WordPress/gutenberg/issues/39307
This PR helps us move towards the design above: https://github.com/WordPress/gutenberg/pull/39353
Now we need to prioritize creating templates for specific slugs (like category-travel, or custom post type templates). I'd imagine we could start with a modal that includes a selector for available terms or post types.
Unless we curate, there could be many available terms, and some could even have the same name. A standard select could get unwieldy.
A modal would be fine, but I still think a search input will generally work best in this flow. If you're creating a specific template you probably have a target in mind. A search input enables you to find that target very quickly.
The tricky part is getting the description right!
Not sure such a generic search would be easier to grasp. Users are used to their categories, tags, post types being a concrete thing. I think we should lean towards the UIs we have in place on the post settings rather than the link UI.
It's not just categories and tags though, we'll also need to list every single post and page as well. Not to mention authors, custom post types and taxonomies. The selection process could be quite convoluted / overwhelming:
Isn't it unlikely that you enter this flow on a whim? Most of the time I suspect you'd already have something in mind that you want to create a template for.
Even if that's a pertty big modal, I kind of appreciate how it shows the breadth of customizability of the templating system. It makes discoverable what is otherwise mystery meat.
Should we move the taxonomy icon to the heading instead of duplicating it for each line inside? Potentially this could also allow us to use the list view inside these boxes, perhaps even starting auto-collapsed, as a means to compactify a bit. We might even be able to do without the max-height and scrollbar for each section. 🤔
Why would we need to combine it all in a single modal? I was hoping that when you create a category template you'd have the option of narrowing it down to a specific category. Same for an archive, etc.
There are many, many ways to slice it, and they all have trade-offs. It sounds like you're suggesting something like this:
It can certainly work. The trade-off is that the popover needs to permanently list all the different types of template a user can create – it could get a bit long / overwhelming when there are many custom post types and taxonomies. For example with WooCommerce installed you might see:
I suppose you can argue that's a separate problem though.
I've been looking into this from the perspective of Woo and merchants needing to add WooCommerce specific templates.
Aside from the issues already discussed in this thread regarding creating specific taxonomy/CPT templates (which would also be an issue for merchants). I have noticed that even though we are able to extend the default templates list via this filter it looks like unless we have a way of extending this list also then the templates will not appear in the dropdown anyway because they get filtered here.
There is also the separate issue (perhaps this isn't the most appropriate place for me to raise but I will do anyway just incase) of new templates being completely blank. Merchants would need to completely rebuild the taxonomy template from scratch every time they wanted to create a variation for each product category.
Happy to discuss further if any of the above does not make sense. Thanks!
new templates being completely blank
There are a few initiatives to tackle this, notably:
- https://github.com/WordPress/gutenberg/pull/37258
- https://github.com/WordPress/gutenberg/pull/39147 (this one is a bit tangential)
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.
