Hugo: Future content issue with `date` and `publishdate` params

Created on 17 Oct 2017  ·  17Comments  ·  Source: gohugoio/hugo

Hugo version: 0.30

From the Hugo CLI documentation:

-F, --buildFuture include content with publishdate in the future

Previous Behavior

  • Hugo will render content with date param set to a future date by default.
  • Hugo will render content with publishdate param set to a future date only with -F or --buildFuture flag enabled.

Current Behavior

But with the 6a30874f19610a38e846e120aac03c68e12f9b7b commit, the value of date & publishdate params will be same if one is absent in the front-matter.

So, content with date param set to a future date will also be considered as future content and will not be rendered by default.

Issue

Clearly one of the mentioned behavior is/was unintended (probably the current behavior, as I saw that the above-mentioned commit fixes an unrelated problem (#3854).

What if someone wants to publish a content with a future date before the date has arrived?

Enhancement

Most helpful comment

What if someone wants to publish a content with a future date before the date has arrived?

I made this change, and I may have stepped on someone's toes here. But the front matter "date logic" is pretty elaborate, and there were several holes in it.

So I still think 0.30 does it right.

So,

  • date is like the created or authored timestamp.
  • publishdate is when it should be published.

To publish content with a future author date:

  • Current date is 2017-10-17
  • You want to publish an article today with author-date 2017-10-20 (not sure why)
  • You should be able to set date=2017-10-20 and publishDate=2017-10-17

So, the change in 0.30 meant that you for the use case above may have to set 2 dates and not just one, which makes sense in my head. Less magic. The important part is that Hugo behaves oddly without a date ... and now it is more likely that we get one.

All 17 comments

What if someone wants to publish a content with a future date before the date has arrived?

I made this change, and I may have stepped on someone's toes here. But the front matter "date logic" is pretty elaborate, and there were several holes in it.

So I still think 0.30 does it right.

So,

  • date is like the created or authored timestamp.
  • publishdate is when it should be published.

To publish content with a future author date:

  • Current date is 2017-10-17
  • You want to publish an article today with author-date 2017-10-20 (not sure why)
  • You should be able to set date=2017-10-20 and publishDate=2017-10-17

So, the change in 0.30 meant that you for the use case above may have to set 2 dates and not just one, which makes sense in my head. Less magic. The important part is that Hugo behaves oddly without a date ... and now it is more likely that we get one.

We have always such a combination on frontmatter.

...
publishdate: 2017-02-14
date: 2017-02-14
...

and in the layouts/shortcodes/lastmod.html this code

{{- if $.Page.Params.LastMod -}}
{{- dateFormat ( or $.Site.Params.dateFormat "2006, Jan 02" ) $.Page.Params.Lastmod -}}
{{- else -}}
{{- dateFormat ( or $.Site.Params.dateFormat "2006, Jan 02" ) $.Page.Params.PublishDate -}}
{{- end -}}

We choose the combo above because the LastMod was not available everytime.

@MunifTanjim please correct me if i'm wrong

See also the older #2145. Without understanding all the intricacies of the discussion above, let me just describe my routine for over a year now: I write posts in advance and want them to come out at a specific date and time. For me, date and publishdate are always the same.

Right now, I add both of them to frontmatter (or rather: copy and edit), but does the 0.30 behaviour mean I can now drop one - and if so, which one?

No big deal either way, just trying to understand. Feel free to close #2145 if it's no longer relevant.

Right now, I add both of them to frontmatter (or rather: copy and edit), but does the 0.30 behaviour mean I can now drop one - and if so, which one?

You can continue to use both if you want (which would also work on <= Hugo 0.30).

For Hugo >= 0.30 you can "do what you want"

  • If you want date (i.e. the author date => .Date) to show up as that "future date", then just set .Date to that date (publish date will inherit that value).
  • Note that in the example above, you could also set publishdate only and it would work the same.
  • If you want date to show up as something different than the publish date, then set both.

So you can usually drop one. But it depends on your use case.

Thanks @bep for explanation.

I as soon as the bugfix for sitemap is released I will test it with 0.30.1.

My use case is to show upcoming events on my homepage as you can see on.

https://www.me2digital.com/events/

I as soon as the bugfix for sitemap is released I will test it with 0.30.1.

To those who wonder why I wait another day 0.30.1 with the release. It is mostly automated, but I will kick my leg if someone reports another critical bug right after I release a patch for that ... So I let it linger a little.

Take your time.
0.29 is perfect okay for me with the publishdate and date solution

I just stumbled upon this behavior when running 0.30.2 on my blog, where I use date for pages representing events, where the value represents the timing of that event -- some of them in the past, some of them in the future.

My expectation was that Hugo will, by default, render all content, unless it's marked as draft, has a past expiryDate or a future publishDate. The very availability of the publishDate variable for me means: if I provide one, respect it, if I don't provide one, just render the content. Now with 0.30.2 suddenly my future events stopped rendering. Took me a while to discover the cause of this unexpected behavior.

I personally prefer the old behavior. Having to add publishDate explicitly seems redundant, because that date for me will be arbitrary, with no relationship to the content, added just to make it render.

Perhaps it's the very existence of date that's confusing, because it's so generic. If we only had lastmod, expiryDate and publishDate (and perhaps creationDate) we'd have all the use cases covered with clear consequences for having each of these defined. In my use case I would then not provide any of these at all, but use a custom eventDate field instead.

@mpaluchowski just to be clear: The current solution to your problem is to set both publishDate and date.

But thinking about it, I think the less confusing thing to do is to adjust the mentioned date logic so:

  • If Date.IsZero, set it to PublishDate if present
  • If PublishDate is Zero, do nothing

I publish future dated events on my sites, but prefer just to use date because it's simple for my users to only think about one date. Setting the buildFuture flag to true works under the current setup for my use-case. Just chiming in because it seems to me the appropriate/expected way for dates to work is, generally speaking, correct now.

I agree with @mpaluchowski to have a custom field like eventDate in comment https://github.com/gohugoio/hugo/issues/3977#issuecomment-338460196

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.

/cc @jinleileiking

I noticed that your 2018-03-20 blog entry mentioned:

用hugo折腾blog有个bug?当date时间在当前时间后,就不显示了。。。

I guess what you are seeing is related to this. I guess you could either use the -F or --buildFuture flag, or to set both date and publishDate as explained by bep above.

I will close this issue, as there is now a way to configure the dates however you want:

[frontmatter]
date = ["date","publishDate", "lastmod"]
lastmod = ["lastmod", "date","publishDate"]
publishDate = ["publishDate", "date"]
expiryDate = ["expiryDate"]

After about 24 hours straight of trying to pinpoint what was going wrong with our site, this was it! I highly recommend you at least add this to the .30 release notes as this would have saved me hours of beating my head against the wall. And I am sure there are others. This is going to require an entire refactor of our site to use publishDate (if possible for what we'er doing). Could you maybe consider adding a flag option like --allowFutureDates to allow dates to be in the future?

Update: I just saw that there IS a --buildFuture flag that works for both publishDate and dates. The flag can also be included in your config.toml file. Thank you.

@bep Could you explain
[frontmatter]
date = ["date","publishDate", "lastmod"]
lastmod = ["lastmod", "date","publishDate"]
publishDate = ["publishDate", "date"]
expiryDate = ["expiryDate"]
please? Or lead me to documentation.

Thanks!

Was this page helpful?
0 / 5 - 0 ratings