-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow adding templates for a single post with a specific taxonomy/term in the Site Editor. #48264
Comments
Related discussion around scaling the template interface #42325 cc @jameskoster for your thoughts here (especially with your Woo background). |
I think the issue here is that the wp template hierarchy does not cater to this use case, and so far as I understand things there's no way to add the necessary logic to something like the |
@jameskoster is right about the template hierarchy and the handling of templates. This seems to me more of a specific term/taxonomy template, which is already handled from the UI. |
Got it! I'm going to close this out in that case. Happy to re-open if needed. |
Hi there, folks! Thanks for your responses, I'd like to offer a new point of view here:
Yes, it is true the native template hierarchy for a single post currently doesn't support this (we also noted this during our exploration), but since on the PHP side, we can rely on a hook (e.g. |
I'm not sure that's quite right. I think the use case here is about displaying single entries with a specific term using a unique template, e.g. "I want everything published in the Recipes category to appear this way". Technically you can already do this by creating a $custom template and applying it manually to all those posts, but that is quite tedious and would have to be done each time you create a new entry. It may still be a short-term solution for you @nefeline ? There does seem to be a valid use case here, but I'm curious about the hierarchy structure. What would happen if templates existed for different terms in the same taxonomy, but a post was assigned to both terms? IE:
Which template gets used there? How can we communicate this to users? How does the add template modal scale to accommodate many taxonomies / terms? I'll re-open for now. Easy to close again if we deem this to be plugin territory. |
The proposed solution by @nefeline would make a lot of sense to me as well. For example, I have a category with "Notes" on my blog, that I want to display differently than other posts. Right now, there's no way (as far as I can tell) rather than:
While it's true that in classic themes we did't have a single-{category}.php template, we did have conditionals! For smaller changes (for example: "If post is of a given category -> don't display a title, or author, or date") we were often using the single.php template with conditionals to check for taxonomies/authors and what-not. As we can't use conditionals in the site editor, this does not seem to be possible at the moment. |
Thanks @jameskoster!
Yes, indeed: While it's possible to manually create custom templates and apply them manually to individual posts, that's suboptimal and doesn't scale: for a website with hundreds/thousands of posts, it can be a challenge to keep up and ensure all individual posts under the same category or term share the same template via manual user input.
In this scenario, if a given post has multiple categories/terms (with custom templates associated with them), an option here could be to automatically list them under the template options for the individual post: Screen.Recording.2023-03-08.at.18.37.29.movLooking forward to hearing your thoughts. |
Yeah, I guess that's the problem I see here. The motivation is to establish automatic template selection and avoid the tedium of manually applying $custom templates. But if determining which template to use is going to wind up involving user intervention anyway, doesn't that defeat the purpose a bit? |
I see your point: one way to circumvent this could be to auto-assign the template for whatever category the user added first, minimizing the user manual intervention to only edge cases, where multiple categories/terms have associated templates.
Avoiding the tedium of manually applying On the PHP side, WordPress already allows extending and modifying the native template hierarchy for a single post via the If not programmatically (have the new template automatically displayed on this modal), at least provide a way for plugin developers to extend it so we can add/remove templates and customize this area, ensuring it is aligned with the extended template hierarchy. |
Some of the use cases (like Notes) could probably be better solved with Post Formats as discussed here #53049, but applying some styling by category would still be nice. Different colors in the header, background etc, depending on category would be something I would use at least. |
@jameskoster @nefeline @annezazu hi there! Do you have any news about this feature? I am setting up a pretty complex website using the new Twenty Twenty-Five theme and this would help me a lot shape my overall structure. |
@PascalClaro there are no further updates here than what you can see above :) |
Even something like adding the taxonomies to the body classes by default would be an improvement. |
What problem does this address?
Currently, it is not possible to add templates for a single post with a specific taxonomy/term in the Site Editor.
What is your proposed solution?
This is a request for making this option available under Templates > Single Item: {post_type}:
On WooCommerce Blocks, we have been exploring different approaches for allowing store owners to add custom templates to individual products depending on their type (simple, grouped, variable, external, etc.). In a nutshell, these are terms of the
product_type
taxonomy. Ideally, we would like to rely on a more robust long-term solution provided by Gutenberg to achieve this goal: we believe this approach can benefit not only Woo, but basically anyone who intends to have a special template for a single post type given its taxonomy.The text was updated successfully, but these errors were encountered: