Hugo: Add ability to generate per-{year, month, day} archives

Created on 29 Aug 2014  Â·  19Comments  Â·  Source: gohugoio/hugo

I'm in process of migrating a blogger based blog to hugo. Compare blogger site to hugo-backed site (source here).

One thing that I'll lose as a result of this migration is an archive of posts (like this one). I don't really care all that much, and I'll most likely replace it with a list of _all_ posts, with a different layout, generated from layouts/section/post.html. I'd like to ask you, however, to consider adding a capability for hugo to generate time-based archives. Such archives would most likely be useful to people who _want_ to preserve their existing archive pages.

It'd generate content under public/<section>/2014/index.html for example, from layouts/post/list.html. It'd need to allow per-section and per-level (yearly, monthly, daily) control. It'd also need to play well with permalinks parameter from config.yaml - I don't really have a good idea how to address that.

Is such feature request a sensible one? :)

Enhancement Keep

Most helpful comment

Thinking out loud here:

  • This isn't related to nested sections (or they are only if you somehow manually assign folders to month, year etc.)
  • I dont't want to create "another thing" in the site config to define some kind of archive tree
  • This on some level related to pagination; "I want to group and create list pages for this selection"
  • Paginators are available for all "node types" with child pages (home page, sections, taxonomy lists, taxonomy terms)
  • Archives could I guess, also be attached to the same noded (most common would be to create an archive below the home page)

Given the above thinking:

  • What if we create a similar lazy setup with some methods on Page: Archive and Archiver.
  • It will group the pages with a function taking the page's publish date, by default possibly "month/year"
  • But make it possible for people to override this in the template: .Archive .RegularPages "some-pattern"

I don't know how to express "some-pattern" in a flexible way, but that sounds solvable.

All 19 comments

An idea for implementation: Generate one index.html file for every level of date-related data present in permalinks from the config file. For example, with:

permalinks:
  post: /:year/:month/:slug

generate

  • /2014/index.html from layouts/section/post.html with .Pages containing all 2014 posts;
  • /2014/01/index.html from layouts/section/post.html with .Pages containing all January 2014 posts.
  • etc.

This should require minimal new logic needed. Some sanity checking might be required, unless we want to allow things like /:month/:year. If you point me to the relevant bit of code where content/* → list of pages to be generated is devised, I might give it a try :)

I actually think this should be a bit different.

This assumes the year/month structure that Jekyll and others use.

I would prefer instead to register every directory and maintain a list of children content regardless of if it's using the permalinks structure or not.

This would not only give us what you need, but also support for subsections.

Does that make sense?

It does make sense - the only question in this kind of schema is how do we decide whether or not render an index.html page? A user may simply not want a file there. Should it be generated by default, or should it be generated only if user asks for an index on given level?

I think by default. It doesn't hurt to have it and you don't need to link
to it. Plus all directories should have an index on the web if they have
content.

On Wednesday, September 3, 2014, Jakub Turski [email protected]
wrote:

It does make sense - the only question in this kind of schema is how do we
decide whether or not render an index.html page? A user may simply not
want a file there. Should it be generated by default, or should it be
generated only if user asks for an index on given level?

—
Reply to this email directly or view it on GitHub
https://github.com/spf13/hugo/issues/448#issuecomment-54388032.

Steve Francia
http://stevefrancia.com
http://spf13.com
http://twitter.com/spf13

I think this is related or the same as #465. Tying them together.

Any progress on this or workarounds?

Any ideas on this one?

FWIW, I've stopped using Hugo for the site that I wanted this feature for, so I'm muting this bug - don't expect any answers here :>

I'm not a Hugo expert and my templates may have some newbie errors but I managed to make archives work using taxonomies.

Check out this repo: https://github.com/mcliment/f1blog-archived/ -there are taxonomies per year defined in config.toml and in every post there's the corresponding frontmatter information-.

The resulting site is here: http://f1blog.climens.net/ with most of the things I had in Wordpress.

Did this one get dropped for good?

I can see how the taxonomy approach would work, but when thinking from a cms point of view I think it would require it to be able to pull the month from the date and add it to the frontmatter without requiring the user to enter redundant data. As well as making sure the config has the needed year taxonomies as time goes on, though I am curious if that part might be able to be done with gulp or something prior to running hugo. I haven't given that any thought just a spur of the moment idea. Anyway, this feature sounds like it was intended to be much more ideal.

Did this one get dropped for good?

It isn't like there are a crazy amount of Hugo developers, and we "all" have our priorities.

serious design limitation

This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help.
If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.
This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.

I find this is still a relevant feature that can be tricked with taxonomies but it's important enough to be a feature in itself.
Many users come from blogging platforms (Blogger, Wordpress...) and every one of them have an archive feature that list posts per year/month/day which can be a convenient way to navigate though the blog.

Thinking out loud here:

  • This isn't related to nested sections (or they are only if you somehow manually assign folders to month, year etc.)
  • I dont't want to create "another thing" in the site config to define some kind of archive tree
  • This on some level related to pagination; "I want to group and create list pages for this selection"
  • Paginators are available for all "node types" with child pages (home page, sections, taxonomy lists, taxonomy terms)
  • Archives could I guess, also be attached to the same noded (most common would be to create an archive below the home page)

Given the above thinking:

  • What if we create a similar lazy setup with some methods on Page: Archive and Archiver.
  • It will group the pages with a function taking the page's publish date, by default possibly "month/year"
  • But make it possible for people to override this in the template: .Archive .RegularPages "some-pattern"

I don't know how to express "some-pattern" in a flexible way, but that sounds solvable.

I am keeping an eye on that as I wish to use it. (I am sad I don't understand much of the code, it's way too abstract to me.)

Really hoping you can come up with a simple to use solution for this as I'm finding it a frustration with Hugo which otherwise I'm loving.

The use of a taxonomy is not scalable but the idea of having something similar to pagination would work for me I think.

Apologies that I don't know GoLang so I'm not able to contribute code here.

This workaround https://blog.atj.me/2017/10/generate-yearly-and-monthly-archive-pages-with-hugo-sections/ was promising for a while but needing to disable the section pages ended up being too much of an annoyance for me.

I wish there was something in the spirit of headless that lets the pages render, but does not make the section page. With that, the above kludge would be ok for now.

Was this page helpful?
0 / 5 - 0 ratings