Add option to create directories from dates

Feature requests
1

Hey, we currently have an open PR porting the rust blog to Zola. One of the concerns raised was changing our URL scheme. On blog.rust-lang.org we have a file scheme of YYYY-MM-DD-post.md which transforms into blog.rust-lang.org/<YYYY>/<MM>/<DD>/post.html.

Currently zola will only strip the date from the file path which makes this style hard to replicate currently. You either have to specify aliases for each post manually, or create a three levels of directories for each post. It would be great if Zola could instead generate this scheme as an option.

This would also solve the problem of being unable to have two posts with the same name but different dates in the same directory, since they’ll have different destinations.

Example Content Layout

posts/
├── 2014-09-15-Rust-1.0.md
├── 2014-10-30-Stability.md
├── 2014-11-20-Cargo.md
└── inside-rust
    ├── 2019-09-25-Welcome.md
    ├── 2019-10-03-Keeping-secure-with-cargo-audit-0.9.md
    └── 2019-10-07-AsyncAwait-WG-Focus-Issues.md

Example Build Output

site
├── 2014
│   ├── 09
│   │   └── 15
│   │       └── Rust-1.0.html
│   ├── 10
│   │   └── 30
│   │       └── Stability.html
│   └─── 11
│        └── 20
│            └── Cargo.html
└── inside-rust
    └── 2019
        ├── 09
        │   └── 25
        │       └── Welcome.html
        └── 10
            ├── 03
            │   └── Keeping-secure-with-cargo-audit-0.9.html
            └── 07
                └── AsyncAwait-WG-Focus-Issues.html
2

On my site I have one section that I’m about to start where I want the date to be the URL (/foo/‹yyyy›/‹mm›/‹dd›/, no slug part), but I don’t want that pattern everywhere on the site—my blog is /blog/‹slug›/ only. I make this work with the use of transparent sections for each year and month.

I have two workarounds to achieve your desire with the current release of Zola, expressing it as a desired output path of /foo/yyyy/mm/dd/slug/:

First workaround: create /content/foo/yyyy/_index.md and /content/foo/yyyy/mm/_index.md and /content/foo/yyyy/mm/dd/_index.md (for each year, month and day), containing this:

+++
render = false
transparent = true
redirect_to = "/foo/"
+++

(You can probably store this as one file and symlink them all to that location. You may want to write a small shell script to automate the creation if you do things this way.)

Then, write your content to /content/foo/yyyy/mm/dd/slug.md. (Or name it /content/foo/yyyy/mm/dd/yyyy-mm-dd-slug.md and skip the date field in the metadata.)

The downside to this is maintaining all the _index.md files. An advantage is that the year, month and date URLs won’t 404, even if it doesn’t present you with a filtered view of all the pages.

Second workaround (probably more palatable): keep the original content/foo/yyyy-mm-dd-slug.md structure, but specify slug = "yyyy/mm/dd/slug" on every page. Yes, slugs can include slashes and it works just fine, so long as you turn off automatic slugification which would kill the slashes. Then, if you want URLs like /foo/yyyy/mm/ to work, figure out how to get the necessary redirect going yourself (e.g. nginx config).

3

I have two workarounds to achieve your desire with the current release of Zola, expressing it as a desired output path of /foo/yyyy/mm/dd/slug/

Neither of these workarounds are really desirable, since they are both quite prone to contributors making a lot of mistakes when adding adding posts such as not putting in the correct metadata or forgetting to move the post when it is time to publish.

I wouldn’t want to be set at the site wide level. It would be much better if it could be enabled at the section level so that you can have some sections such as a blog have the date in the URL, and have the rest of the website behave like it does currently.

4

This kind of URL scheme will not happen in Zola: https://github.com/getzola/zola/issues/635#issuecomment-524564469
I still haven’t changed my mind on them and wish they would stop being used in general.

1 Like
5

Thank you for your response! To address points one and two in the linked issue, I would be willing to contribute an implementation for review, and having dated posts is part of the point on our blog, as it isn’t meant to be act to be evergreen documentation. Our blog posts are rarely updated beyond typos or corrections after they’re published. Of course if you still feel strongly against the inclusion of this feature then there isn’t much I can do.