.Lastmod does not honor front matter override

support
1

Using .Lastmod in template, and getting only the git lastmod. lastmod property in front matter is ignored.

post front matter:

---
title: Range Damage
author: Stets Newcomb
lastmod: "2017-03-03T14:15:59-06:00"
---

template:

{{ define "main" }}
	<div id="page-wrapper" class="smaller-viewport">
		<section class="news">
			{{ range .Pages }}
			<article>
				<div class="date">
					<span class="month">{{ .Lastmod.Format "Jan" }}</span>
					<span class="day">{{ .Lastmod.Format "02" }}</span>
				</div>
				<div class="excerpt">
					<h2>{{ .Title }}</h2>
					<address>{{ .Params.author }}</address>
					{{ .Content | truncate 90 }}
				</div>
			</article>
			{{ end }}
		</section>
	</div>
{{ end }}

Month and day are “DEC” and “13” – the day I did git checkin. If I haven’t checked it in yet, its 01-01-0001T00:00:00-00:00

According to documentation the front matter should override file metadata.

2

If you have enableGitInfo set to true in your config, then it will override the front matter lastmod value.

See date configuration docs for more info.

3

I am using git, and generally want the git info, but there are a few posts that I need to back date. Is it correct to say then that it is impossible to backdate posts and use gitinfo?

4

I think so.

But, you could get around this by using a different param for lastmod. Create a new one, say lastmodified, then use that in your templates.

1 Like
5

Allow me a rant for a moment.

This behavior is not consistent. If you’re not using git, you can use the lastmod param to override the file metadata. If you are using git you cannot. It would be more consistent to either allow an override or not, regardless of where the primary data is stored.

Practically, this results in template developers having to make special concessions as you say, to create a nonstandard front matter attribute for what should be pretty straightforward to handle.

6

You came with a problem, I offered a working solution.

Now, keep in mind, I’m still learning Hugo. So others may (will likely) have better explanations for why things are the way they are. I could also be missing something here.

CC @bep @kaushalmodi

7

There is definitively a consistency in there.

You can say:

  • Use lastMod (front matter), but fall back to Git if not set
  • Use Git (if enabled), but fall back to lastMod
  • Many variations of the above, including using system file timestamp

What we don’t support is, say, use lastMod for some files, but use Git for the others. That would, in my head, be very inconsistent … But there may be something I don’t see, so please explain.

8

I was expecting .Lastmod to use the author defined lastmod property if present, then fall back to either git or stat.st_mtim inference.

This would be the same behavior as several other hugo features. For instance: slug, which uses the front matter override if present, but falls back to an inference of the file basename.

9

You can configure Hugo to behave that way. It’s just not the default behaviour.

See

2 Likes
10

Ok. I’m officially impressed. Thanks @bep.

1 Like
11

Oh nice. So now I can have best of both :+1:. Thanks as well @bep

[frontmatter]
lastmod = ["lastmod", ":git", "date", "publishDate"]
1 Like