Allow for future posting by date in front-matter. #260

Closed
pawelurbanski opened this Issue Apr 19, 2014 · 29 comments

Projects

None yet

5 participants

@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
Owner
spf13 commented Apr 19, 2014

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:
#260 (comment)

@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:
#260 (comment)

@spf13
Owner
spf13 commented Apr 19, 2014

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:
#260 (comment)


Reply to this email directly or view it on GitHub.

@spf13
Owner
spf13 commented Apr 19, 2014

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:
#260 (comment)


Reply to this email directly or view it on GitHub.

@tubia
tubia commented Apr 30, 2014

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
Contributor
nathany commented Apr 30, 2014

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
Owner
spf13 commented Apr 30, 2014

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
Contributor
nathany commented Apr 30, 2014

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
Owner
spf13 commented Apr 30, 2014

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
Contributor
nathany commented Apr 30, 2014

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

@spf13
Owner
spf13 commented Apr 30, 2014

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
Contributor
nathany commented Apr 30, 2014

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:
#260 (comment)

@spf13
Owner
spf13 commented Apr 30, 2014

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
Owner
spf13 commented Apr 30, 2014

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
Contributor
nathany commented Apr 30, 2014

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:
#260 (comment)

@nathany
Contributor
nathany commented Apr 30, 2014

@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:
#260 (comment)

@spf13
Owner
spf13 commented May 1, 2014

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
Contributor
nathany commented May 1, 2014

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:
#260 (comment)

@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:
#260 (comment)

@spf13
Owner
spf13 commented May 1, 2014

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:
#260 (comment)


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:
#260 (comment)


Reply to this email directly or view it on GitHub.


Reply to this email directly or view it on GitHub:
#260 (comment)

@tubia
tubia commented May 2, 2014

@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.

@spf13 spf13 closed this in c502f07 May 29, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment