Taxonomy term order affected by associated page having date

support
1

I’m seeing a date on a page affect the sort order of a tag that page has in the tag taxonomy.

I have pages _index.md, a.md, and b.md in content/ with tags I, A, and B respectively. When no page has a date, the tags are listed at URL /tags/ in alphabetical order A, B, I, as expected, but when I add a date to b.md, then I see order B, I, A.

I don’t understand this behavior. There is no tag page like content/tags/b/_index.md, so the page for the B tag can’t have a date. No weights are used. That means the default sorting should be using the titles, right?

Regardless of what’s going on with b.md and the B tag, why is the I tag listed before the A tag now too?

Is this somehow related to that breaking change that made list pages inherit the date of its latest page? Again, if so, how does that explain the order of the I and A tags?

Thanks for any help!

Using: hugo v0.143.1+extended+withdeploy darwin/arm64 BuildDate=2025-02-04T08:57:38Z VendorInfo=brew

hugo.toml:

baseURL = 'https://example.org/'
languageCode = 'en-us'
title = 'My New Hugo Site'

[taxonomies]
tag = "tags"

content/_index.md:

---
title: I
tags: [i]
---
I

content/a.md:

---
title: A
tags: [a]
---
A

content/b.md:

---
date: "2023-09-18T20:21:05-07:00"
title: B
tags: [b]
---
B

layouts/_default/baseof.html:

<html>
	<body>
		{{ block "main" $page }}{{ end }}
	</body>
</html>

layouts/_default/list.html, layouts/_default/taxonomy.html, layouts/_default/term.html:

{{ range .Pages }}
{{ .Title }}
{{ end }}

layouts/_default/single.html:

{{.Title}} - {{.Content}}
2

looks like if the term is not backed by a file the newest date from assigned pages is used.

I observed when changing the date of a the page hugo server did not pick that up and the list of tags stays in old order. If the term has a page, changing a date there works.

I cannot reproduce that one - for me the order is b - a - i when B has a date

p.s. as a workaround you may use .Pages.ByTitle or .Data.Terms.Alphabetical in the taxonomy template. (guess you know that)

3

To clarify… If you’re referring to https://github.com/gohugoio/hugo/pull/12633, that was specific to the publication date. Yes, while that PR changed the value returned by Page.PublishDate, it intentionally fixed a bug where publishDate did not “roll up” like date and lastmod. The “roll-up” strategy is applicable to section, taxonomy, and term pages, and has been in effect for a very long time, perhaps since inception.

The behavior you are seeing is correct.

When you add a date to content/b.md:

  1. If taxonony/tags/b.html does not exist, its date is rolled up from its members (i.e., content/b).
  2. If taxonony/tags/b.html does exist, but does not have any dates defined, its date is rolled up from its members (i.e., content/b).

In your example you did not add a date to content/_index, so its date is rolled up from its members (i.e., content/b).

That means that five pages have the same date:

  • content/b (date set in front matter)
  • content/tags/b (date rolled up from content/b)
  • content/tags (date rolled up from content/tags/b / content/tags/i [same dates])
  • content/_index (date rolled up from content/b)
  • content/tags/i (date rolled up from content/_index)

So, when rendering content/tags, the sort order should be B, I, A. B and I have the same date (indeterminate sort), so when we sort by title we get B, I followed by A (because it has a zero date).

To me, a “workaround” is a temporary solution to a bug or behavioral deficiency. The current behavior is neither.

1 Like
4

yeah, actually I ment circumvent (i guess that would be the right word)

1 Like
5

I see, it makes sense now. Thanks for the thorough explanation. I’ll have to use a custom sort order.

In my opinion, this is another data point for why list pages shouldn’t inherit publish dates from their subpages, and the behavior should either be compat-broken, or the default sort order should be customizable to use a new field that only reflects the list page’s front matter.

6

Right, fair enough. I was thinking that it broke my program.

7

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