Some time ago, I migrated my WordPress blog to Jekyll for different reasons including performance, security, and hosting costs - but mainly because I lost too much time maintaining the platform and the plugins up-to-date. So far, I’m very happy about the result.
But I had to change the way I’m writing posts I intend to publish later. In WordPress, the process is very simple: write a draft anytime you want; edit it to your heart’s content and when ready, hit publish. Done.
Jekyll is quite different. The site is generated statically so that there’s no magical button to click in order to publish. Posts are written in Markdown (or Asciidoc): in order to get the HTML, the site needs to be generated.
There are several ways to manage the management of publications with Jekyll. This post is dedicated to a few of them.
Using future dates
Posts are stored in a specific _posts folder.
Each post is tagged with a publish date.
When generating the HTML site, only posts whose publish date are not after the date of the day are generated.
Given the above behavior, the easiest way to publish is just to create posts with a date set in the future. That way, on D-day, re-generating the site will publish the new post.
In order to preview the generated post before that date, the generation process can be launched with the --future option.
This strategy requires to know the date a post will be published in advance. If no publication date can be planned, the next strategy is useful.
Using drafts
In order for a post to be generated, it needs to have its type meta-data set to… post.
This is the case by default.
But if the type is set to draft, they won’t be generated unless Jekyll build is launched with the --drafts option.
For better management, all such drafts can (should?) be stored in a _drafts folder.
When one wants to publish a draft, change the type from draft to post - and optionally move it to the main posts folder.
Using a VCS
When using a Version Control System - and I do hope it’s the case, posts/drafts can also be written in a specific publication branch e.g. feature/new_posts.
Changing branch will preview those new posts with no consequence to the master branch.
Publishing requires just cherry-picking the commit of the wanted post.
Of course, it’s possible to combine cherry-picking with the above options to achieve full flexibility.
| As an added benefit to cherry-pick new publications from a dedicated branch, this branch can be cleaned up from time to time to keep the number of posts low, and the generation time as well. |
My way
That’s currently how I manage my publishing flow:
- If I planned a specific publication date
-
- Commit the new post in the publication branch,
feature/new_posts - Cherry-pick it the day of the publication
- Generate the site
- Commit the new post in the publication branch,
- If there’s none
-
- Same as above
- Optionally move the file from the
_draftsto the_postsfolder - Amend the cherry-pick to:
- Change the type from
drafttopost - Add the correct date
- Change the type from
- Generate the site as above
| This way works quite well for multiple writers, with the editing process handled through Pull Requests. |