Post dates in URLs / "transparent sections"

[porglezomp]

I'm trying to migrate my site over from Pelican right now.
I'd like to keep the same page organization, with pages at /posts/yyyy/mm/slug/.

I've managed to get most of the way there by reorganizing my content directory to have explicit date folders, added _index.md to all of them, and built a template that iterates over the nested sections.

Unfortunately, I think I've hit a roadblock—pagination doesn't seem like it'll work on the posts if I have nested sections, since none of the posts are direct children of posts.

The most flexible solution to my problem would be to be able to request that the year and month sections are "transparent" or "transitive" or something, so that every page in posts/2018/09 is also a page in posts/2018 and posts, allowing pagination and sorting to work.

It might also be nice to have some easier support for nested sections like this that doesn't require having an _index.md in every single subfolder, but that's just a ergonomics, not fundamentally different.

[Keats]

I'd like to keep the same page organization, with pages at /posts/yyyy/mm/slug/.

First, keep in mind this URL layout is not supported by Gutenberg on purpose.

The transparent approach does look interesting though, let me think about it a bit more.

[Keats]

How would transparent sections interact with the potential #284 ?

The main usecase I see for transparent sections is a single one for #413 IF you have pagination so in theory not too much.
Anyone else needs this feature outside of yyyy/mm/dd and homepage paginated section?

[pkgw]

I'm also interested in this feature. My main interest is that I have a lot of blog posts and I just won't want to store them in a single directory with 1,000 files in it.

@Keats Perhaps this is documented somewhere, but why does Gutenberg not support/encourage a YYYY/MM/slug URL layout?

[Keats]

why does Gutenberg not support/encourage a YYYY/MM/slug URL layout?

Mostly because it tries to be discoverable but fails in practice: if you don't post in a month no entry will be generated for that YYYY/MM period so that will be a 404.
Second issue: I'm updating an already published page, a good chunk of content is new but the URL will still say it's old. It isn't great for user discoverability since users might see an old date and skip it because they think it's outdated content.
Lastly and this one I'm not too sure about is from a SEO perspective. I believe Google will pick up the date from the URL as the main source of truth for the content date, even if you have an update.

We can debate on those points but in the end that's a feature I'm not really interested in and don't want to maintain.

WRT transparent sections, one of the issues not mentioned was the slowness it could cause: the parent section would get all the pages but also all the subsections with their pages, resulting in having pages present 2-3x in the result. #480 should make that cost disappear, if you have any feedback on it.

[pkgw]

@Keats That makes sense. It's not something that I feel particularly strongly about (particularly since I confirmed that I can emulate the old paths with the path setting), I was just curious what the reasoning was.

I don't have any feedback on #480 besides to say that it seems like a good idea to me!

[jwatt]

A use case that I have is a small family website where family members have their own blog section with a structure like /blog/{username}/{posts}, and want the website's homepage to contain a chronological list of all posts by all family members.

Perhaps a way to support this would be to allow users to specify the location of a section's pages in the _index.md's frontmatter using a simple wildcard pattern (the wildcard only matching entire directory names). In my case I'd add something like:

get_pages_from = "blog/*/"

(Maybe for_pages_in would be a better name.)

The section would then ignore any .md pages in its own directory (maybe the build should error out if there are any) and instead gather up all the pages in the /blog/{username}/ directories and treat them as its pages.

[Keats]

I have pushed it to the next branch, would be useful to get feedback.