`Lastmod` is recursive on Page Bundles?!

support
1

My content directory structure is:

_index.md
posts/
  _index.md
  post1/
    index.md
  post2/
    index.md
  post3/
    index.md

For the three posts I set publishDate in the front matter, because I want to display this on the website.
Now when I access the lastmod of either of the parent page bundles (posts/_index.md and _index.md) I expect them to not be set to anything. (Since I didn’t set any date for these files by hand and don’t have the git thing enabled.) However, they are set, from the publishDate of the descendents!

Is this intended? I couln’t find anything about this on the documentation. How do I disable this? I want independent dates for index pages.

2

https://gohugo.io/getting-started/configuration/#configure-dates

3

Sorry, I don’t see how this should help. I know this page. I also know that lastmod can be inherited from publishDate. But from another (child) page?! There is no comment on that on the page you sent, if I’m not mistaken.

4

They are not.

I’d have to look at your project to give you a definitive answer, otherwise I’m just guessing.

5

I’m guessing that you have not set a date in either _index.md or posts/_index.md. In which case this is what you want to do:

[frontmatter]
lastmod = [‘lastmod’]

6

First, here is working example: GitHub - jbirnick/testsite

You can see that it the lastmod date is indeed inherited from child pages. This is described nowhere in the documentation? Is it a bug?

7

Please confirm.

8

Yeah I didn’t set any dates in the other files; just as in the example repo that I linked.

9

If you don’t set a date on section or home page, then is doesn’t have a date. We want (and sometimes need) a date for every page. In the absence of date on section or home page, we choose the most recent date in the section.

And that can be controlled by:

https://gohugo.io/getting-started/configuration/#configure-dates

So either change your config, or add a date to the home and section pages.The default archetype populates the date, and there’s a reason for that.

10

But publishDate also falls back to date, and in the example you can see that it doesn’t get inherited?

11

Is it possibly lastmod that is actually inherited, not date?

12

(Sorry for the amount of posts.)

It is very confusing that date and lastmod (and others) fall back to each other circularly. For example, from the webpage you can see that:

  • publishDate falls back to date
  • date falls back to lastmod

In the example I sent, publishDate and date are both not set. So publishDate should be lastmod by the above chain. But you can see in the example that it isn’t.

It would be great to see whats actually going on under the hood, and in what order.

13

If you are trying to test this real time with hugo server, make sure you print to console with warnf because hugo server does not refresh in all situations.

The rules it follows are:

[frontmatter]
  date = ['date', 'publishDate', 'lastmod']
  expiryDate = ['expiryDate']
  lastmod = [':git', 'lastmod', 'date', 'publishDate']
  publishDate = ['publishDate', 'date']
1 Like
14

Yeah I already realized that hugo server has difficulties with it. So I only test these things with usual builds.

I know the rules that you sent. As I said, they are circular, so they don’t tell you everything. You also need to know the order of execution. See my previous response.

For me it now works with lastmod = ['lastmod'], so you don’t need to waste more time on this. I just wanted to make people aware that the documentation doesn’t tell you everything:

  • it doesn’t tell you about inheritation (and I still don’t know which date is actually inherited)
  • it doesn’t tell you about the order of fall back executions
15

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.