Allow for future posting by date in front-matter.

[pawelurbanski]

I would like to propose ability to future post content. I do know that we have Drafts functionality but allowing for future dates in posts would be very useful. One could for example: set a date in the future and get the post published at some later time. I guess it is only a matter of 1 or 2 If statements comparing current date and time to the date and time of the content being generated. If Current Date / Time <= Date / Time of Content generate it. We can obviously check if the content is not in a Draft state.

Thaks for considering.

[spf13]

Seems like a good idea. Wanna make a pull request?

Steve Francia spf13.com @spf13

On Apr 19, 2014, at 9:13 AM, pawelurbanski notifications@github.com wrote:

I would like to propose ability to future post content. I do know that we have Drafts functionality but allowing for future dates in posts would be very useful. One could for example: set a date in the future and get the post published at some later time. I guess it is only a matter of 1 or 2 If statements comparing current date and time to the date and time of the content being generated. If Current Date / Time <= Date / Time of Content generate it. We can obviously check if the content is not in a Draft state.

Thaks for considering.

— Reply to this email directly or view it on GitHub.

[pawelurbanski]

Yes, I will but I won't be able to help with the code that much.

On 4/19/14, Steve Francia notifications@github.com wrote:

Seems like a good idea. Wanna make a pull request?

Steve Francia spf13.com @spf13

On Apr 19, 2014, at 9:13 AM, pawelurbanski notifications@github.com wrote:

I would like to propose ability to future post content. I do know that we have Drafts functionality but allowing for future dates in posts would be very useful. One could for example: set a date in the future and get the post published at some later time. I guess it is only a matter of 1 or 2 If statements comparing current date and time to the date and time of the content being generated. If Current Date / Time <= Date / Time of Content generate it. We can obviously check if the content is not in a Draft state.

Thaks for considering.

— Reply to this email directly or view it on GitHub.

---

Reply to this email directly or view it on GitHub: https://github.com/spf13/hugo/issues/260#issuecomment-40872113

[pawelurbanski]

I tried to create a pull request but had some minor issues interacting with GH under a screen reader. I am blind and some sites are better or worse than others. I will be glad if someone makes a pull request or feature request for me.

Allow to generate posts in the future based on their front-matter date and time. Everything is described in this issue at the beginning.

On 4/19/14, Pawel Urbanski pawel@e-urbanski.com wrote:

Yes, I will but I won't be able to help with the code that much.

On 4/19/14, Steve Francia notifications@github.com wrote:

Seems like a good idea. Wanna make a pull request?

Steve Francia spf13.com @spf13

On Apr 19, 2014, at 9:13 AM, pawelurbanski notifications@github.com wrote:

I would like to propose ability to future post content. I do know that we have Drafts functionality but allowing for future dates in posts would be very useful. One could for example: set a date in the future and get the post published at some later time. I guess it is only a matter of 1 or 2 If statements comparing current date and time to the date and time of the content being generated. If Current Date / Time <= Date / Time of Content generate it. We can obviously check if the content is not in a Draft state.

Thaks for considering.

— Reply to this email directly or view it on GitHub.

---

Reply to this email directly or view it on GitHub: https://github.com/spf13/hugo/issues/260#issuecomment-40872113

[spf13]

I can just cherry pick from your git branch. Thanks!

Steve Francia spf13.com @spf13

On Apr 19, 2014, at 12:25 PM, pawelurbanski notifications@github.com wrote:

I tried to create a pull request but had some minor issues interacting with GH under a screen reader. I am blind and some sites are better or worse than others. I will be glad if someone makes a pull request or feature request for me.

Allow to generate posts in the future based on their front-matter date and time. Everything is described in this issue at the beginning.

On 4/19/14, Pawel Urbanski pawel@e-urbanski.com wrote:

Yes, I will but I won't be able to help with the code that much.

On 4/19/14, Steve Francia notifications@github.com wrote:

Seems like a good idea. Wanna make a pull request?

Steve Francia spf13.com @spf13

On Apr 19, 2014, at 9:13 AM, pawelurbanski notifications@github.com wrote:

I would like to propose ability to future post content. I do know that we have Drafts functionality but allowing for future dates in posts would be very useful. One could for example: set a date in the future and get the post published at some later time. I guess it is only a matter of 1 or 2 If statements comparing current date and time to the date and time of the content being generated. If Current Date / Time <= Date / Time of Content generate it. We can obviously check if the content is not in a Draft state.

Thaks for considering.

— Reply to this email directly or view it on GitHub.

---

Reply to this email directly or view it on GitHub: https://github.com/spf13/hugo/issues/260#issuecomment-40872113

— Reply to this email directly or view it on GitHub.

[spf13]

You will need to push it to a public repo though first.

Steve Francia spf13.com @spf13

On Apr 19, 2014, at 2:05 PM, Steve Francia steve.francia@gmail.com wrote:

I can just cherry pick from your git branch. Thanks!

Steve Francia spf13.com @spf13

On Apr 19, 2014, at 12:25 PM, pawelurbanski notifications@github.com wrote:

I tried to create a pull request but had some minor issues interacting with GH under a screen reader. I am blind and some sites are better or worse than others. I will be glad if someone makes a pull request or feature request for me.

Allow to generate posts in the future based on their front-matter date and time. Everything is described in this issue at the beginning.

On 4/19/14, Pawel Urbanski pawel@e-urbanski.com wrote:

Yes, I will but I won't be able to help with the code that much.

On 4/19/14, Steve Francia notifications@github.com wrote:

Seems like a good idea. Wanna make a pull request?

Steve Francia spf13.com @spf13

On Apr 19, 2014, at 9:13 AM, pawelurbanski notifications@github.com wrote:

I would like to propose ability to future post content. I do know that we have Drafts functionality but allowing for future dates in posts would be very useful. One could for example: set a date in the future and get the post published at some later time. I guess it is only a matter of 1 or 2 If statements comparing current date and time to the date and time of the content being generated. If Current Date / Time <= Date / Time of Content generate it. We can obviously check if the content is not in a Draft state.

Thaks for considering.

— Reply to this email directly or view it on GitHub.

---

Reply to this email directly or view it on GitHub: https://github.com/spf13/hugo/issues/260#issuecomment-40872113

— Reply to this email directly or view it on GitHub.

[tubia]

This possible feature could have a wider use. For example, we could be able to condition other fields. Let's say I have a content type: event. This content type has a field to control manually if an event is outdated or not. It's called outdated, a boolean variable. We could be able to change from false to true if current Date >= Event_Date. I hope this explanation it's not so confused :)

[nathany]

For meetup sites, I post with a future date (date of the event) but still show future posts.

Just want to double check that this is possible (in the process of converting from Jekyll to Hugo).

[spf13]

I agree with the overall request to hide future dated posts. Initially this field was called pubdate which still works. I made it date to make it easier for conversions from other SSGs which all use date. 

While it is currently possible, I would probably rename that field to event_date or similar to not confuse it with the pubdate or date field.

We could make this a flag, but I’d prefer not to since publish date seems quite clear that it shouldn’t be visible before that date is reached. 

Does that make sense?

Best, Steve

--  Steve Francia http://stevefrancia.com http://spf13.com http://twitter.com/spf13

From: Nathan Youngman notifications@github.com Reply: spf13/hugo reply@reply.github.com Date: April 30, 2014 at 8:42:02 AM To: spf13/hugo hugo@noreply.github.com Cc: Steve Francia steve.francia@gmail.com Subject:  Re: [hugo] Allow for future posting by date in front-matter. (#260)

For meetup sites, I post with a future date (date of the event) but still show future posts.

Just want to double check that this is possible (in the process of converting from Jekyll to Hugo).

— Reply to this email directly or view it on GitHub.

[nathany]

What is the interaction between date (or pub date) and permalinks?

I can add other dates for other purposes, but I want the date used in the permalink to not disallow future posts from being visible, whereas others will want to do just that.

Jekyll just has a flag. Future: true.

[spf13]

I see.. that makes sense, didn’t consider the permalink relationship. 

I suppose adding the flag makes sense given that relationship. 

Best, Steve

--  Steve Francia http://stevefrancia.com http://spf13.com http://twitter.com/spf13

From: Nathan Youngman notifications@github.com Reply: spf13/hugo reply@reply.github.com Date: April 30, 2014 at 11:12:41 AM To: spf13/hugo hugo@noreply.github.com Cc: Steve Francia steve.francia@gmail.com Subject:  Re: [hugo] Allow for future posting by date in front-matter. (#260)

What is the interaction between date (or pub date) and permalinks?

I can add other dates for other purposes, but I want the date used in the permalink to not disallow future posts from being visible, whereas others will want to do just that.

Jekyll just has a flag. Future: true.

— Reply to this email directly or view it on GitHub.

[nathany]

Just a flag in config.yaml. I'm not sure what the default should be.

[spf13]

Default should be to not show future.. which will be a behavior change from now where we show all posts (except drafts) by default. I think this follows the principle of least surprise.

I also believe that boolean flags should be enabled by setting them to true... meaning the default should always be false.

[nathany]

SGTM. Thanks.

[pawelurbanski]

Hi Guys, Pelican which is another static generator works as follows: Ther eis a flag: WITH_FUTURE_DATES : FALSE / TRUE. If the flag is TRUE and the date of the post is in the future then the post is flagged as Draft and then the standard flagging of drafts and generating them or not comes into play.

Home that it is a kind of idea...

On 4/30/14, Nathan Youngman notifications@github.com wrote:

SGTM. Thanks.

---

Reply to this email directly or view it on GitHub: https://github.com/spf13/hugo/issues/260#issuecomment-41810117

[spf13]

I think that’s a mistake. There’s no reason to combine these two ideas. There’s far more control when you keep them independent.

[whereisaaron]

Good discussion. I don't like this sort of global flag on philosophical grounds:

• they lead to the same front matter having different meanings depending on the flag
• they lack flexibility/control since they apply globally to websites

I'd prefer that the front matter had multiple dates:

• 'date': the date displayed and used for permalinks
• 'pubdate': (optional) the date this page/item starts being published
• 'expiredate': (optional) the date the page/item stops being published

You could still have a global flag, but that flag - if enabled - would cause the 'pubdate' to default to 'date', so any page without a 'pubdate' would use the 'date' value to decide whether the page is published. Any page with an explicit 'pubdate' would override that default. If this flag was not set, anything without a future 'pubdate' would be published.

In this way people migrating from Jekyll can still easily have the same behaviour, without cramping the flexibility/control for Hugo users.

The idea of using expressions to evaluate whether to publish or not sounds great. But it needs some thinking through, and a solid simple approach like above should be the first, before we add more complex options.

Q: Should dates are allow a time as well? Running Hugo hourly and rsync-ing the content seems reasonable for controlling publish times for better audiences. And some websites (live blogging?) may like to display times.

[spf13]

Dates allow times today. TOML has native support for an actual date type. For the others, strings are cast as dates using one of the formats defined at https://github.com/spf13/cast/blob/master/caste.go#L226

[nathany]

Without the flag, people wanting to prevent publishing on a given date need to set pubdate to the same date as date. The global "future" flag seemed pretty pragmatic to me, but I only mentioned it because it's what Jekyll does.

In terms of managing expectations, this is a static-site generator, so maybe having a "publish on a date" isn't the best idea. Everything needs to be regenerated anyway, and how much more work is it to flip from draft to published for the individual posts when doing that?

For people who want to hide articles based on date, it should be easy enough for a template author to put conditions on the date to exclude it from the index. Maybe even single.html could have a check against any date and not show the content. All the tools to hide posts based on any criteria and any fields instead of building in one specific way to do it.

[pawelurbanski]

I asked about this feature for the following case: I write a few articles on my laptop / desktop. Upload them to a server. Run a cron job every X hours. Posts get publish without babysitting draft flags...

On 4/30/14, Nathan Youngman notifications@github.com wrote:

Without the flag, people wanting to prevent publishing on a given date need to set pubdate to the same date as date. The global "future" flag seemed pretty pragmatic to me, but I only mentioned it because it's what Jekyll does.

In terms of managing expectations, this is a static-site generator, so maybe having a "publish on a date" isn't the best idea. Everything needs to be regenerated anyway, and how much more work is it to flip from draft to published for the individual posts when doing that?

For people who want to hide articles based on date, it should be easy enough for a template author to put conditions on the date to exclude it from the index. Maybe even single.html could have a check against any date and not show the content. All the tools to hide posts based on any criteria and any fields instead of building in one specific way to do it.

---

Reply to this email directly or view it on GitHub: https://github.com/spf13/hugo/issues/260#issuecomment-41848394

[nathany]

@pawelurbanski Oh. Nice idea to have a cron job.

[whereisaaron]

@nathany my proposed 'date-is-default-pubdate' flag provides exactly was you wanted. You can just convert from Jekyll with just 'date' fields, enable the flag and only pages with past date/times will be published. You need never add a single 'pubdate' field ever if you prefer the Jekyll way.

I think it is a mistake to view a static-site-generator as a necessarily occasional process. The pages are hosted and served as static pages, that is the point, but they can be updated as frequently as you wish. You could generate on a live server every minute if you wished. The example given by @pawelurbanski is one use case. And I want to be able to use cron job so I don't have to get up in the middle of the night to remove the draft flag from a page scheduled for another country.

@nathany manipulating the index is insecure, since the page will still be published, just not listed in the index. You could include date-test expressions in the single template to hide content (like you suggest), but then you are adding expressions to indexes and to templates to achieve a very common use case of date/time-based content publishing. And if you are happy to do that, then you don't need the global flag to achieve Jekyll behaviour anyway :-)

[pawelurbanski]

Thanks for all the replys, but the kind request is... Can anyone of you post an example YAML front-matter block where the default publishing date is used, so one doesn't have to use "date" and "pubdate" set to the same date to generate posts as the case describes?

Thanks a lot, dear friends

On 5/1/14, Aaron Roydhouse notifications@github.com wrote:

@nathany my proposed 'date-is-default-pubdate' flag provides exactly was you wanted. You can just convert from Jekyll with just 'date' fields, enable the flag and only pages with past date/times will be published. You need never add a single 'pubdate' field ever if you prefer the Jekyll way.

I think it is a mistake to view a static-site-generator as a necessarily occasional process. The pages are hosted and served as static pages, that is the point, but they can be updated as frequently as you wish. You could generate on a live server every minute if you wished. The example given by @pawelurbanski is one use case. And I want to be able to use cron job so I don't have to get up in the middle of the night to remove the draft flag from a page scheduled for another country.

@nathany manipulating the index is insecure, since the page will still be published, just not listed in the index. Security by obscurity.

---

Reply to this email directly or view it on GitHub: https://github.com/spf13/hugo/issues/260#issuecomment-41866795

[spf13]

I love all the interest and feedback on this post.

I've considered all the options presented and feel that the best solution is the simpliest.. and actually a mixture of all ideas presented thanks @pawelurbanski @nathany @whereisaaron .

'date': the date displayed and used for permalinks (optional) uses publishDate if missing
'publishDate':  the date this page/item starts being published (optional..) if missing, always publish

• Entirely avoids a global flag, and places the control more granularly on each content to determine when it is live.
• Doesn't change the current behavior of posting everything without a publishDate.
• Keeps a clean separation between the elements but also is clear that the only time you need a second one is when the publish date is different from the permalinks date.

It fits all of the use cases suggested in the comments above:

Cron based 'go live' @pawelurbanski Just set the publishDate on your content and it will just work.

Pub date independent of permalink date @nathany Just set the date on your content and it will just work.

It also permits for the union of these two (which no other suggestion does) Cron based 'go live' with an independent permalink date Set both date and pubdate on the content

I can't think of a reason to use expireDate, but given the above changes it would be easy enough to add. @whereisaaron or others : What's a good use case for it?

Sound good?

[nathany]

SGTM. I don't personally have a use case for expireDate atm.

[pawelurbanski]

I think, it is a very good idea. :) I will play with those options by creating a few sample posts with different date combinations. Github is not extremely accessible in some areas and I use a computer with a ascreen reader so... I will be glad to contribute a few words to the manual, but someone would need to create a pull request on my behalf.

On 5/1/14, Nathan Youngman notifications@github.com wrote:

SGTM. I don't personally have a use case for expireDate atm.

---

Reply to this email directly or view it on GitHub: https://github.com/spf13/hugo/issues/260#issuecomment-41923097

[pawelurbanski]

I made some simple tests. And here are the results with current Hugo release.

I created a post with the following front-matter:

title: "Date test" date: "2014-05-05" pubdate: "2014-05-05"

And the variation with publish_date instead of pubdate with: "2014-05-05".

The page is always generated, but I guess it shouldn't?

On 5/1/14, Pawel Urbanski pawel@e-urbanski.com wrote:

I think, it is a very good idea. :) I will play with those options by creating a few sample posts with different date combinations. Github is not extremely accessible in some areas and I use a computer with a ascreen reader so... I will be glad to contribute a few words to the manual, but someone would need to create a pull request on my behalf.

On 5/1/14, Nathan Youngman notifications@github.com wrote:

SGTM. I don't personally have a use case for expireDate atm.

---

Reply to this email directly or view it on GitHub: https://github.com/spf13/hugo/issues/260#issuecomment-41923097

[spf13]

I haven’t committed the code for this functionality yet, just wrote up the idea on this to confirm it worked for everyone. Will get to it in the next few days.

Best, Steve

--  Steve Francia http://stevefrancia.com http://spf13.com http://twitter.com/spf13

From: pawelurbanski notifications@github.com Reply: spf13/hugo reply@reply.github.com Date: May 1, 2014 at 2:21:28 PM To: spf13/hugo hugo@noreply.github.com Cc: Steve Francia steve.francia@gmail.com Subject:  Re: [hugo] Allow for future posting by date in front-matter. (#260)

I made some simple tests. And here are the results with current Hugo release.

I created a post with the following front-matter:

title: "Date test" date: "2014-05-05" pubdate: "2014-05-05"

And the variation with publish_date instead of pubdate with: "2014-05-05".

The page is always generated, but I guess it shouldn't?

On 5/1/14, Pawel Urbanski pawel@e-urbanski.com wrote:

I think, it is a very good idea. :) I will play with those options by creating a few sample posts with different date combinations. Github is not extremely accessible in some areas and I use a computer with a ascreen reader so... I will be glad to contribute a few words to the manual, but someone would need to create a pull request on my behalf.

On 5/1/14, Nathan Youngman notifications@github.com wrote:

SGTM. I don't personally have a use case for expireDate atm.

---

Reply to this email directly or view it on GitHub: https://github.com/spf13/hugo/issues/260#issuecomment-41923097

— Reply to this email directly or view it on GitHub.

[pawelurbanski]

Thanks Steve and apologies for jumping to conclusions too quickly.

On 5/1/14, Steve Francia notifications@github.com wrote:

I haven’t committed the code for this functionality yet, just wrote up the idea on this to confirm it worked for everyone. Will get to it in the next few days.

Best, Steve

Steve Francia http://stevefrancia.com http://spf13.com http://twitter.com/spf13

From: pawelurbanski notifications@github.com Reply: spf13/hugo reply@reply.github.com Date: May 1, 2014 at 2:21:28 PM To: spf13/hugo hugo@noreply.github.com Cc: Steve Francia steve.francia@gmail.com Subject:  Re: [hugo] Allow for future posting by date in front-matter. (#260)

I made some simple tests. And here are the results with current Hugo release.

I created a post with the following front-matter:

title: "Date test" date: "2014-05-05" pubdate: "2014-05-05"

And the variation with publish_date instead of pubdate with: "2014-05-05".

The page is always generated, but I guess it shouldn't?

On 5/1/14, Pawel Urbanski pawel@e-urbanski.com wrote:

I think, it is a very good idea. :) I will play with those options by creating a few sample posts with different date combinations. Github is not extremely accessible in some areas and I use a computer with a ascreen reader so... I will be glad to contribute a few words to the manual, but someone would need to create a pull request on my behalf.

On 5/1/14, Nathan Youngman notifications@github.com wrote:

SGTM. I don't personally have a use case for expireDate atm.

---

Reply to this email directly or view it on GitHub: https://github.com/spf13/hugo/issues/260#issuecomment-41923097

— Reply to this email directly or view it on GitHub.

---

Reply to this email directly or view it on GitHub: https://github.com/spf13/hugo/issues/260#issuecomment-41939051

[tubia]

@spf13 expireDate could be useful if you think at a content type like event. Using this case: Date: the event date (displayed in the permalink, etc.) publishDate: the date the event start to be displayed expireDate: the date the event stop to be displayed

It could be useful also to have similar fields, not to hide content but to change status of another field. Let's say I want to have a featured post from may 5 to may 7, controlled by the field featured. I set something like:

ftrstartDate: 05-05-2014
ftrstopDate: 07-05-2014

In this case ftrstartDate change the featured status from false or not set to true. Then ftrstopDate change the featured status from true to false. Maybe this one is a slightly different feature.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.