Add date to front matter when publishing draft

[jandudulski]

Conceptually mostly the same thing as #54 but should add date to existing file when running jekyll publish path/to/draft

[alzeih]

I had a go at implementing this but I can't see a good way to solve this without introducing code that could destructively alter source files and cause unexpected behaviour with posting dates.

The easiest nearly fix would be to add a date to a draft when it is created, but this then causes problems publishing with the --date option as the two dates may disagree. Even having a unique sentinel like value to find and replace with the publish date wouldn't work if a post was published then unpublished.

Parsing source files and altering their contents seems like a recipe for breaking or losing posts. Maybe publishing could try to set the published date in the front matter and not remove the draft so the original isn't lost, but it could still cause lost or corrupted posts so would need to try to explain this to the user every time they published... yuck.

Do you have a better idea I've missed?

[jandudulski]

My general idea was that the script would:

• load draft file
• split file into a front matter object and content
• check if there is a date field already and prompt to verify if user wants to overwrite it
• add date field to front matter object
• create a new file with updated front matter and the content

But unfortunately, I haven't had time yet to take a look at how complicated it might be to implement.

[pathawks]

My general idea was that the script would

I think this is the right approach

[alzeih]

If you like, take a look at #63.

[alzeih]

Hmm, instead of altering the file contents as well with publish and unpublish, what about a separate jekyll touch command?

It can alter any post, draft or not. Jekyll seems to prefer the yaml front matter over the filename for posts, so jekyll touch doesn't need to move the file for the new date to apply (and jekyll unpublish then jekyll publish would move the file to the current date).

All the logic for prompting the user and/or making backups before editing files would be handled by that command, and not mixed with publish and unpublish.

Downside: in some cases, more than one command is needed to publish a draft. Also, published posts with dates that are unpublished with a date must be touched to be correct.

Upside: simplifies publish and unpublish. Editing file front matter (or even contents) can then be used by another command and the prompting/backup behaviour can be shared. e.g: renaming posts, additional front matter, a edit command to open EDITOR?

[pathawks]

Has PR #63