Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

List page publish date now defaults to that of the latest subpage #12653

Open
willfaught opened this issue Jul 11, 2024 · 5 comments
Open

List page publish date now defaults to that of the latest subpage #12653

willfaught opened this issue Jul 11, 2024 · 5 comments
Labels
Bug NotSure
Milestone
Unscheduled

Comments

@willfaught
Copy link

willfaught commented Jul 11, 2024 •
edited
Loading

I see all my list pages have a value defined for PAGE.PublishDate when there shouldn't be any. This seems to have changed in a recent version, but I don't know which.

Repro for a new/blank site:

layouts/_default/list.html:

<html>
<body>
{{.PublishDate}}
</body>
</html>

layouts/_default/single.html:

<html>
<body>
{{.Title}}
{{.PublishDate}}
</body>
</html>

content/_index.md:

+++
title = "Main"
+++

content/foo.md:

+++
title = "Foo"
date = 2022-04-02T12:45:03-07:00
+++

http://localhost:1313/foo/ content:

Foo 2022-04-02 12:45:03 -0700 PDT

Expected http://localhost:1313 content:

0001-01-01 00:00:00 +0000 UTC

Actual http://localhost:1313 content:

2022-04-02 12:45:03 -0700 PDT

This change appears to have been part of a bug fix: #12438

I would argue that the previous behavior (where PAGE.PublishDate worked like every other page kind) is better because:

  • It makes PAGE.PublishDate behave the same for all page kinds, which matches the current documentation. List pages can have a title, description, content, and front matter parameters of their own, and .PublishDate should reflect those parameters, like it does for the other page kinds.
  • The name "PublishDate" is unclear in the context of list pages: Is it the .PublishDate of the first page in the sub page list, or is it the publish date of the first published page (not including draft or expired pages or pages with future publish dates)?
  • The current behavior seems only suitable for feeds like Atom or RSS, where you would want to indicate the last change date for a section's feed. The previous behavior is more suitable for HTML, where partial templates are reused across default templates like list.html and single.html (like displaying the .PublishDate). While feeds are important, HTML is by far the more common and important use case.
  • The current behavior can be computed manually and portably across modules/themes by ranging the sub-pages and tracking the latest .PublishDate, but the previous behavior (including the configured fallbacks in site config) cannot be done portably across modules/themes.
  • If enabling the current behavior really is desirable, it can be done with a new field instead, which is time.Time{} for non-list pages.

First reported at https://discourse.gohugo.io/t/list-page-publish-date-now-defaults-to-that-of-the-latest-subpage/50634.

What version of Hugo are you using (hugo version)?

$ hugo version
hugo v0.128.2+extended darwin/arm64 BuildDate=2024-07-04T08:13:25Z VendorInfo=brew

Does this issue reproduce with the latest release?

Yes.
@bep
Copy link
Member

bep commented Jul 11, 2024

See #12438

@bep bep closed this as completed Jul 11, 2024
@willfaught
Copy link
Author

@bep It seems that you didn't read this issue. I linked to #12438 in it. What are your thoughts on the points I made in this issue?

@willfaught
Copy link
Author

@bep Also, if the ultimate decision is to not revert the .PublishDate behavior, then we should follow through and fix the .PublishDate documentation to reflect the current behavior:

With Hugo’s default configuration, the PublishDate method returns the front matter value. This behavior is configurable, allowing you to set fallback values if the publish date is not defined in front matter.

@bep bep reopened this Jul 11, 2024
@bep
Copy link
Member

bep commented Jul 11, 2024

With Hugo’s default configuration, the PublishDate method returns the front matter value. This behavior is configurable, allowing you to set fallback values if the publish date is not defined in front matter.

The above is still correct. If you add publishDate to front matter in e.g. mysection/_index.md then that is the value that's getting published.

The current behaviour matches how we treat both date and lastMod and is what most people would expect.

If you don't want to show publishDate for sections, then you can do a {{ if .IsPage }}{{ .PublishDate }}{{ end }} or something..

@willfaught
Copy link
Author

willfaught commented Jul 11, 2024 •
edited
Loading

The above is still correct.

But it's incorrect if no date-like params are set. For other page kinds, if no date-like params are set, then .PublishDate is time.Time{}. That isn't the case for list pages. This special list page behavior is unspecified here and elsewhere.

If you don't want to show publishDate for sections, then you can do a {{ if .IsPage }}{{ .PublishDate }}{{ end }} or something.

I do want to show it if a date-like param is set, according to the configured fallbacks. As I pointed out above, there's currently no portable way to do this.

The current behaviour matches how we treat both date and lastMod

Then my argument should apply to them too. That does admittedly increase the scope of change. If you don't want to make breaking changes (again) like that, then I understand, but then how about a new field that implements the previous behavior? Something like PAGE.PublishDateNotRecursive (similar to PAGE.RegularPagesRecursive)?

(Edited)

@bep bep added this to the v0.130.0 milestone Jul 22, 2024
@bep bep added NotSure and removed NeedsTriage labels Jul 22, 2024
@bep bep modified the milestones: v0.130.0, v0.131.0 Jul 30, 2024
@bep bep modified the milestones: v0.131.0, v0.133.0 Aug 9, 2024
@bep bep modified the milestones: v0.133.0, Unscheduled Aug 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Bug NotSure
Projects
None yet
Milestone
Unscheduled
Development

No branches or pull requests
2 participants
@willfaught @bep