Add an option to integrate the date into the path

[jplatte]

It would be helpful for large blogs to avoid path clashes by introducing an option that incorporates the date into the path of pages in a collection.

@Keats were you thinking of /{year}/{month}/{day}/{slug}? That's what I currently have and probably the most common way to have the date in the path.

---

Honestly I think having an option to integrate the date in the path would suffice, no need for full blown custom url patterns.

Originally posted by @Keats in https://github.com/getzola/zola/issues/635#issuecomment-971693646

[Keats]

I was more thinking /{yyyy-mm-dd}-{slug}. The /{year}/{month}/{day}/{slug} doesn't make any sense to me, unless you build the pages for each days/month/years

[jplatte]

I think I get what you mean by it not making sense, but this is what many pages do (even without having those sub-pages; an example would the Rust project's blog) and personally I also think it looks the best.

[mwcz]

This made me think of one SSG I used to use, I think it was Pelican, which did generate list pages along the /{year}/{month}/{day} paths, and I found that kind of cool. I seem to remember Jekyll having /{year}/{month}/{day}/{slug} paths as well, but it didn't/couldn't generate list pages. I currently use Hugo (I'm still converting to Zola!) and it doesn't generate list pages for the dates either. So, at least the irrationality of /{year}/{month}/{day} is already well-accepted!

I might be in the minority on this last point, but I find the /{day} part unnecessary. /{day} doesn't help much with slug name conflicts, and doesn't help readers identify the age of a post quickly. I use /{year}/{month}/{slug} on my blog, and I'm not even sure about keeping /{month}. Please make date paths configurable with a format string. :pray:

[mikae1]

The /{year}/{month}/{day}/{slug} doesn't make any sense to me, unless you build the pages for each days/month/years

I partly agree, but having at least a directory for year does make sense if you want Zola to scale well. Possibly having thousands upon thousands of post in a directory isn't optimal. Here's my take: /{year}/{month}{day}-{slug}, i.e. /2022/0124-the-slug. No, /2022/ dir isn't a browseable archive, which may not be what the user expects. But, at least I can rest assured an opinionated SSG won't be making my life miserable in 2042. 😆

Also, the example from the page documentation quoted below:

The file content/blog/2018-10-10-hello-world.md will yield a page at [base_url]/blog/hello-world. With optional whitespace, the file content/blog/2021-01-23 -hello new world.md will yield a page at [base_url]/blog/hello-new-world

...does have a collision problem. If slug is the same (for two or more posts) there will be filename collisions or ugly sequence numbering.

Lastly, there are of course plenty people coming from other SSGs or CMSs that would like to keep their cool URIs. Not supporting what (just about) every SSG and CMS out there offers makes it impossible or difficult to make the switch.

Glad you're at least considering some implementation of dates in URLs. This is the only thing keeping me away from Zola. I check in about once a year to see if what's happening. 😀

[skyfaller]

I was in the habit of using /{year}/{month}/{day}/{slug}/ from WordPress and would like to keep my cool URIs.

My Hugo sites don't currently generate browseable archives, but I decided to use Caddy web server to simply let visitors browse a directory index (dynamically generated, but pretty darn fast). You can see it in action if you navigate to https://www.maximumethics.dev/blog/2020/ for example. I could do more to make this look better, but it works, it lets you find blog posts from that year.

In other words, Zola doesn't necessarily have to generate browseable archives for each part of the date-based path for a Wordpress-style URL to be useful.

[Endle]

I was in the habit of using /{year}/{month}/{day}/{slug}/ from WordPress and would like to keep my cool URIs.

I'm not sure if /{year}/{month}/{day}/{slug}/ is a good practice, but many blog engines support that style, including Jekyll. If Zola supports this URL format, migrating from Jekyll to Zola could be easier

[jplatte]

I'm once again involved with porting a site to Zola that uses this URL scheme for the blog section.

@Keats would you accept a PR that adds this functionality? I don't have a strong opinion on how it would be configured / how flexible it should be, but I need the /{year}/{month}/{day}/{slug} to be amongst the supported patterns, otherwise it makes no sense for me to work on it. I would be happy to go the extra mile and generate index pages for /{year}/, /{year}/{month}/ and /{year}/{month}/{day}/ if you think that makes this path style more worthwhile.

[Keats]

Honestly I'm still not convinced by this feature.

[skyfaller]

@Keats Are you saying that you do not see the value of preserving URLs when moving a website to Zola?

Whatever design decisions you might make if you were building the Web from scratch, the reality is that a large percentage of the Web runs on Wordpress, WordPress is used by 42.8% of the top 10 million websites as of October 2021. Its default URL scheme is therefore dominant. Many sites that run other SSGs, like Hugo and Jekyll, originally ran on Wordpress and maintain that URL scheme. Others just began using it because it's what they were used to seeing, but they're committed now.

There are no doubt plenty of other idiosyncratic URL schemes from less popular CMSes, some of them including the date, and it would help those people move to Zola if they could put the date in their path. I jumped in the WayBack Machine and looked at my ancient PHPosxom site from 2003, and even that had the date in the permalink URLs, although it was after a "?". I also glanced at a Movable Type site I moved to Wordpress once upon a time, and that had dates in the permalinks in 2005: http://web.archive.org/web/20050901155801/http://www.warnewsradio.org/show/

Many people, possibly including me, will not switch their sites to Zola if they cannot preserve their existing URL scheme.

What are your criteria for a desirable feature? What would convince you that this feature is desirable?

[Keats]

What are your criteria for a desirable feature? What would convince you that this feature is desirable?

The issue is having the whole permalink configuration like Hugo does: https://gohugo.io/content-management/urls/#permalink-configuration-values It adds a whole layer of complexity that was not there before

[skyfaller]

It adds a whole layer of complexity that was not there before

Thank you for clarifying. I agree with simplicity as a goal. Excessively complex software becomes impossible to debug or maintain, also sluggish / resource-intensive. I encourage you to make Zola "as simple as possible, but not simpler." But I'm not sure you've answered my question: how do you decide what features are worth the added complexity? What goals do you have besides simplicity? (Speed when building sites?)

If simplicity were my top priority, I think there are simpler SSGs, even simpler SSGs written in Rust. Would you agree that Blades is significantly simpler than Zola? Yet it can technically support date-based URLs, for people who are willing to manually write URL paths/slugs for each post: https://github.com/grego/blades/issues/19

I don't think this is an ideal solution, but are manual URLs doable for Zola? Perhaps that would be "good enough" for some users. If not, what is different about Blades's design that allows it to support a (half-ass) solution despite its simplicity? (Blades also may be faster than Zola, if that's a primary design goal.)

[Keats]

how do you decide what features are worth the added complexity? What goals do you have besides simplicity? (Speed when building sites?)

No specific criteria, just me deciding

Yet it can technically support date-based URLs, for people who are willing to manually write URL paths/slugs for each post: https://github.com/grego/blades/issues/19

You have been able to do that in Zola as well, with the exact same syntax, for many years? What this thread is requesting is to generate those URLs automatically from the given date in the front-matter.

The issue regarding simplicity is that imo, having /2022/10 in a url should imo generate archives pages (see what @jplatte is mentionning above) but we don't have that concept yet. If we add it, we should also add ways to generate them for sites without the year in the url and the complexity goes us quite a bit.

[ludwick]

As I attempt to convert my WP blog to a static site generator (trying out Zola & Hugo), I am pondering whether I actually care about this. But I have figured out how to do it which I hope you don't mind me leaving a note here with how I did it for anyone else who might be considering it.

I have a basic plan on wordpress.com so my only real option was to export it in their xml format, then used blog2md to get it into markdown files with sort of reasonable frontmatter in yaml format. Since Zola quickstart recommended blog content in ./content/blog that's where I put the markdown files. First blocker was the date format in wordpress xml is not supported by Zola. Easy fix:

ruby -rdate -i.bak -pe 'sub(/^date: (.*)$/) { "date: #{DateTime.parse($1).iso8601}" }' content/blog/*

To get it to emit the posts at the paths my current blog does -- /YYYY/MM/DD/<slug> -- I used another ruby one-liner:

ruby -i.bak -r date -pe '(if /^date: (.*)$/ then d = DateTime.parse($1); slug = File.basename($FILENAME).sub(/\.md$/, ""); path = d.strftime("%Y/%m/%d"); puts "#{$_}path: \"#{path}/#{slug}\""; next; end)'  content/blog/*.md

zola serve seems to put things in the right place with this.

Note that blog2md seems to make the files be named the same as the last path component of where wordpress says the post comes from -- so if a blog post is at /2022/01/02/foo-bar in wordpress, then blog2md extracts that post into a file foo-bar.md. If your posts don't follow that convention, then the above one-liner will not be helpful to you. :)

All that said, I am considering just letting zola put things where it wants to by default and when I get to the point of actually deploying it, I might just add redirect rules to nginx (or similar).

[nikhilweee]

Looks like this won't be added anytime soon, but for those wanting to have the year in the URL, this is the solution I came up with. Let's say you want to group posts by year. Structure your blog in this manner:

content/first-post.md
content/2024/_index.md
content/2024/newest-post.md
content/2023/_index.md
content/2023/old-post.md

As for the section template, you can use the following snippet to show posts from a subsection:

    {% set subsections = [section.relative_path] | concat(with=section.subsections) %}
    {% for subsection in subsections %}
        {% set section = get_section(path=subsection) %}
        {% for page in section.pages %}
            {{ post.title }}
            {{ post.permalink }}
        {% endfor %}
    {% endfor %}

This way the section page will not only display its children (first-post.md), but also its grandchildren (newest-post.md and old-post.md). Of course this is a workaround, but I think it's still better having no support at all.