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

[yacoob]

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? :)

[yacoob]

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 :)

[spf13]

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?

[yacoob]

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?

[spf13]

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 notifications@github.com 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

[spf13]

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

[matrixik]

Just for example from Wordpress: https://wordpress.org/plugins/compact-archives/ http://www.wpbeginner.com/archives/

[AriaFallah]

Any progress on this or workarounds?

[vielmetti]

Any ideas on this one?

[yacoob]

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 :>

[mcliment]

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.

[smakinson]

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.

[bep]

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.

[COLABORATI]

serious design limitation

[stale[bot]]

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.

[mcliment]

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.

[bep]

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.

[22decembre]

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.)

[TotallyInformation]

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.

[tv42]

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.

[asmaier]

We have 2021 and this ticket is now open for seven years (and so it is the oldest ticket still open here). It is surprising for a newcomer to hugo to see such a basic functionality missing given that hugo has no problems auto-generating pages for tags and categories. And it is not that this feature isn't needed. The internet is full of workarounds to this problem:

• https://discourse.gohugo.io/t/monthly-archive-pages-for-blog/122
• https://discourse.gohugo.io/t/pagination-and-group-by-date/1441
• https://randomgeekery.org/post/2016/04/yearly-post-archives-in-hugo/
• https://blog.atj.me/2017/10/generate-yearly-and-monthly-archive-pages-with-hugo-sections/
• https://smartshitter.com/musings/2017/12/monthly-archive-and-proper-pagination-in-hugo/
• https://discourse.gohugo.io/t/how-to-generate-chronological-blog-archives-in-hugo/13491/4
• https://melcher.dev/2019/01/inconvenient-hugo-yearly/monthly-archives/
• https://www.thedroneely.com/posts/generating-archive-pages-with-hugo/
• https://rohanverma.net/blog/2019/11/15/archive-pages-group-by-year-hugo/
• https://github.com/gohugoio/hugo/issues/6992
• https://www.jayeless.net/2021/04/taxonomies-archive-hugo.html

I collected these just to underline the need for this feature. It would be very nice if you could consider giving this feature a higher priority. I think hugo should not release v1.0 before it hasn't implemented automatic generation of a per-{year, month, day} archive if hugo wants to be a relevant framework for bloggers.

[jmooring]

@asmaier

Thank you for this list.

Although their approaches may be imperfect, to characterize the authors' efforts and generosity as "half baked" is... unfortunate.

[asmaier]

Sorry, I did not mean to belittle the work of the authors of these solutions. English it not my mother tongue. I edited my post and now call these solutions workarounds. I hope that is a more neutral description.

[President]

Any news here? Will this be implemented. This is a blocker issue!

[asmaier]

Will this ticket ever be solved?

Just a quote from one of the workarounds

So there you have it! This is the method I’ve used to create monthly archives for my blog in Hugo. It might seem like a lot of effort for something that other blogging platforms handle by default, but it works, and isn’t too much ongoing effort once set up.

• https://www.jayeless.net/2021/04/taxonomies-archive-hugo.html

[jmooring]

For anyone still interested in archives by year, month, and day...

git clone --single-branch -b hugo-forum-topic-46777 https://github.com/jmooring/hugo-testing hugo-forum-topic-46777
cd hugo-forum-topic-46777
rm -rf prebuild/public/ public/ && hugo -s prebuild && hugo server -e production

It's really easy to do:

• No extra front matter fields to manage
• No external scripts
• Widgets are easy to create, e.g.

Make sure to read the README.

[metbril]

for those who want to read first: https://github.com/jmooring/hugo-testing/tree/hugo-forum-topic-46777

[asmaier]

For anyone still interested in archives by year, month, and day...

git clone --single-branch -b hugo-forum-topic-46777 https://github.com/jmooring/hugo-testing hugo-forum-topic-46777
cd hugo-forum-topic-46777
rm -rf prebuild/public/ public/ && hugo -s prebuild && hugo server -e production

It's really easy to do:

• No extra front matter fields to manage
• No external scripts
• Widgets are easy to create, e.g.

Make sure to read the README.

I'm trying to wrap my head around this. So I understand you are basically using a first hugo run on the prebuilt directory to create a directory structure for the archive. Then the second run of hugo will mount the output of the first run into it's content directory and make use of the prebuilt directory structure to create daily, monthly and yearly archives. Is this correct?

So from what I understand the first hugo run is basically just a "misuse" of hugo as an external script. That is smart, but doesn't seem like a convincing solution to me. I think from a user perspective I would like to see the prebuilt step being done by hugo internally if some config option in hugo.toml is activated, e.g. enableArchiveByDate. Would something like this be possible?

[asmaier]

For anyone still interested in archives by year, month, and day...

git clone --single-branch -b hugo-forum-topic-46777 https://github.com/jmooring/hugo-testing hugo-forum-topic-46777
cd hugo-forum-topic-46777
rm -rf prebuild/public/ public/ && hugo -s prebuild && hugo server -e production

It's really easy to do:

• No extra front matter fields to manage
• No external scripts
• Widgets are easy to create, e.g.

There is one thing I'm missing from this example. The year.html, month.html and day.html used to generate the yearly, monthly and daily archive do not offer a link to the next and previous archive page. So I would expect on the page posts/2022 to have a link to the next archive at posts/2023 and to the previous one at posts/2021. The same for monthly , e.g. on the page posts/2022/01/ I would like to have a link to the previous month posts/2021/12 and to the next month posts/2022/02 . Can this be done? This would then also solve https://github.com/gohugoio/hugo/issues/6992 .

[jmooring]

@asmaier The list pages are paginated. So in additional to prev/next on each pager pointing to the previous or next pager, you also want navigation to the next/previous year/month/day? That seems a bit busy to me, but probably do-able.

[asmaier]

So in additional to prev/next on each pager...That seems a bit busy to me

You are right. I don't want additional navigation, but instead have a different alternative date based pagination instead of the normal pagination.

[asmaier]

@jmooring I found a way how to create the navigation between the date based sections of your example code as I imagined it. I opened a pull request https://github.com/jmooring/hugo-testing/pull/4 . This might not be the perfect code, but maybe it helps to understand better what I want.

[22decembre]

Hello.

I have an interest in this issue. I see that solutions are being proposed. Does it means there will be such a thing in the near future ?

Thanks

[jmooring]

This uses a relatively simple module to create year, month, and day archive pages for one section of a site. The module leverages the content adapters feature introduced in v0.126.0.

The module itself requires v0.126.2 or later.

Example:

git clone --single-branch -b hugo-github-issue-448 https://github.com/jmooring/hugo-testing hugo-github-issue-448
cd hugo-github-issue-448
mkdir -p assets/data
hugo mod verify
hugo list published > assets/data/published-content.csv
hugo server

Details: https://github.com/jmooring/hugo-module-archive

Note that this approach relies on the hugo list published command, for which there is no API promise. Although the output of this command is unlikely to change in a breaking fashion, such breakage is a possibility, and may require a change to the module in order to provide forward compatibility.

[raoulb]

Any updates on this? What are the current plans to get archives (without workarounds)? Especially as #6992 was closed with reference to this issue here.