It’s quite restrictive that taxonomies live at [taxonomy]/single.html and [taxonomy]/list.html. Would it be possible to allow customisation of these paths?
In addition, could taxonomies have associated meta data, specifically a place to store a description of the taxonomy and a description of each term within it?
What’s the use-case there?
I would just chuck that in the [extra] section of the config or in the templates directly.
Tags for sections. For example, if I have a section /games/ I can’t also have a taxonomy [games] because it’ll live at the same location as the section which Zola doesn’t allow. I can’t see a way around this with the current implementation, unless I’m missing something?
I did try that in the config, but it starts to get very unwieldy for many taxonomies and terms. Adding them directly to templates is unworkable as I keep content and structure separated.
I think I could make a workaround using external text file descriptions and use load-data. I’ll investigate that.
I see. You were talking about the template path but you actually want to change the output path, that makes more sense
Ah yes, that’s exactly it, sorry for any confusion. Perhaps then an output path could also be allowed as part of the taxonomy definition? For example:
taxonomies = [
{ name = "games", path = "games/tags", feed = true}
]
Any chance that custom output paths for taxonomies will become a feature? I frequently need to do section based tags and have had to create messy post-build scripts to sort it all out. Would be awesome if Zola could support it out of the box.
I was fiddling around with Zola recently trying to make the same thing work, and it turns out if you set slugify to false on taxonomies, it’ll interpret the slashes as a path? So creating a taxonomy like “resources/layouts/tags” actually puts the taxonomy stuff in the resources/layouts/tags folder.
You’d think it wouldn’t work, but it does, apparently.
Huh! I tried it and it works. Sorta. The files are generated at the path as you discovered, but because taxonomies are no longer slugified, the URLs are ugly and need more thought when linking in content. I’m not sure that change is worth the bother, but it’s an interesting technique nevertheless. Likely a bug really, but clever to exploit it this way.
I’m almost considering learning Rust just so I can raise a PR for this feature. Because I don’t really understand why it’s not made it into any new releases: it would be incredibly useful and really improve Zola’s ability to provide more flexibility for self contained sections with their own taxonomies. One can live in hope I guess…
a bit of a necro (sorry), but I’m circling back to this from searching around and not finding an ‘easy’ solution here thus far for this general usecase.
The problem I’m encountering is:
/blog/tags/, /music/genre/, /music/artists/)The current solution I’ve landed on, from the above, is finally:
(thankfully, my taxon data is already generated by a script from some other tomls, so I know that in my case, the taxon term names are slug-friendly A-Za-z0-9_-, which makes my life much easier)
I’ve realized that the upside of this approach is that I’m able to use the ‘same’ taxon name in the different contexts & keep them separate, e.g. “blog/tags” and “music/tags”, so I’m not really sure what an actually good solution would look like here.
Yes, this is a nice way to do it if you don’t need slugified taxons, but that’s a deal breaker for me. I had to switch to Kirby CMS and its SSG plugin for sites that need this feature, which in itself has become a huge pain since that requires PHP: the draw of Zola was always the single binary that runs anywhere.
Please can we get a solution for this, @keats? It’s been over two years of asking, and there are other requests for this feature from even earlier. There’s even an open PR for it. I’m not a rust programmer and can’t contribute to the PR, but is there anything else I can do to help get this over the line?
I would take a PR for section specific taxonomies, the PR you linked should probably be closed