I want the url of post1 to be /post1 instead of /section1/post1. Is there any way to do that?
Currently, I have make it work by setting path in post index.md. However, in my project, I have multiple nested sections to organize posts by year, category, etc.
I need to hide some section slugs in url to make it clean. If I use path in every page, It would be inconvenient to add prefix for each one.
I am looking for something similar to this as well. I have a couple hundred posts now in by the /content/blog/ folder, and I’d just like to organize them for my own purposes to try and reduce clutter, and make it easier for myself to find recent posts.
I would love to be able to have my folder structure be /content/blog/{year}/{post} format, but have the slug just be /blog/post I agree with Keats’ post about not including years in the url and that is what I currently have, and what I am trying to keep.
I’m just looking for a way of achieving this by setting path in a /content/blog/2025/_index.md and have that base path for everything in the ./2025 directory but I seem to not be able to do that.
Is there any way to achieve this without having to set path on every post?
I like to keep my markdown files organised in subfolders off my content folder, such as /journal/ or /books/. This makes it easy to find related content during the creation/editing process. However, I don’t want these sub-folders as part of the final URL because all content is presented as a single stream and all post slugs should be at the top level of the site tree, eg, www.site.com/slug-of-each-post.
I know there’s the path override but as noted by the OP, it’s tiresome to have to write this in the front-matter for thousands of files when we already know its slug. I also don’t want to put the markdown files at the content root as that’s just a huge old mess and a recipe for chaos.
I propose a config option that will allow us to control whether a folder is included in the post’s path when generated. It could follow the format of the ignored_contentoption and simply be a table of folder names to remove from paths at render times, eg:
ignored_foldernames = [“journal”, “books”]
Then the output renderer could check against this and perform the necessary adjustments to the final location of the rendered posts. Would something like this be possible?
Another option could be to allow pattern matching in the path variable, perhaps something like this path = “/*” or path = “/dir1/dir2/*” where the asterisk is replaced by the slug at render time? If this path could also be setup in the section template, it would apply to all pages in that section, removing the need to add path to any individual page.
@Tecknet The transparent option doesn’t do anything with slugs, paths or urls. It’s just a way of making parent pages “aware” of the posts in subfolders, for building listings/index pages, etc.
@keats Hi, I was wondering if you have any thoughts on this issue? Would it make sense to bring it over to Github as a feature request?
(FYI, having thought about it a bit more, perhaps the easiest way to control it is by a flag in the section front-matter, eg flatten = true – where flatten simply means don’t render the section slug as part of the final URL for the pages in that section.)
I thought transparent is used to make ancestors aware of lower pages for listing purposes on parent/sections? It doesn’t change the output path of the original page.
Eg, if I have a section /journal that contains a lot of pagesXYZ.md and I want those pages paths to not include /journal when output, setting transparent doesn’t help with that. Should it?
My understanding is that the only way to override the output path in this case is to add a path to the page’s frontmatter, and the path would just duplicate the slug which is a bit redundant because we already know the slug. And it becomes impractical to do this for hundreds of pages.
So the discussion here is about how to ignore /journal in the output path without adding path to all the relevant pages. Is there a way currently?
That’s fine I suppose, but it doesn’t really help if you use the filename as the slug: if you later want to edit the filename/slug, you now also have to edit the path in the frontmatter too. Or one could have both the slug and the path in the frontmatter, but that’s even sillier.
I’d like a method of “flattening” out the folder name so that it’s not included in the output path, rather than having to use the path setting.
It seldom happens, and having to edit the path/slug is so quick&easy anyways
changing URLs should be avoided anyways in any web site
reorganizing file names implies some manual decisions anyways. For instance, to keep the old path as an aliases so that existing URLs never break but are redirected.
Again, each new feature in a system has a (hidden) cost in maintenance, robustness… there is no free lunch.
I would argue — in my personal opinion — that adding a feature that has a cost on each build even though its functionality can be provided easily by existing means (or a simple script) that only costs once, at page creation, is opposite to the design decisions that attracted me — and I guess others — to Zola.
PS: coding a script in your favorite language that will “flatten” your URLs by editing the paths is trivial.
Zola sells itself on being a single binary to make websites. I approach it with the same mindset. This is why I make feature requests to be added to Zola itself, rather than needing to write other external scripts to handle missing features. I guess we see things differently.
Yes, but Zola is opinionated. If you want flexibility first, you may have to look for other tools designed with this goal in mind (e.g. with plugins) rather than struggle against the tool, especially an opinionated one. The “Zola mindset” is not just “one binary”.
Like most good tools, Zola brings you a lot of convenience and power, if you agree to its design philosophy.
Take another example: git.There exist a lot of front-ends or ancillary scripts to use git comfortably for all kind of people that have different needs. Adding all these features into git core would make it lose a lot of its appeal and technical advances.
PS: my advice:
Build a prototype Zola site. Not a mere “hello world”, but trying to get what you want, but do not spend too much time. LLMs can help you a lot for this stage.
Then, pause, and read the whole Zola docs. They are not so big, and easy to read once you have some personal experience with the tool.
Now that you get the “Zola mindset”, re-design your site from scratch.
That’s quite a condescending response. I didn’t ask for your advice.
I’ve been a web designer and developer since the 90s. I’ve used Zola for five years, I’ve learned it in depth and built many different things with it. I understand it very well thank you, and I do not need to ask you or an LLM to help me. And I think you missed the point of this thread.
There’s a good reason why people don’t respond well to unsolicited advice. Learn it.