Implementing the Missing Drafting and Queueing Function in Octopress
It’s been a while since I first started using Octopress. Its simple and elegant way of writing has now become my de facto standard of writing, but there are still things to be desired. For one thing, the workflow consisting of writing, commiting, compiling and deploying is still not lazy enough; ideally the only thing that should be required of the writer is to write. Inspired by Dennis Wegner in his Synced and scheduled blogging with Octopress, I worked on a bash script to allow for friction-free, painless deployment process that goes totally automatic underhood.
A short summary of the tinkering
- Like in Dennis’es original post, two new folders called
_queueare added to the
sourcedirectory to hold drafts and queued posts respectively.
Again, just like in the original post, you can put any markdown files within the
_draftsfolder; as soon as there’s the
published: trueproperty within the YAML front matters like this
--- published: true ---
Then the draft will be moved to the
- All the files within the
_queuefolder will be checked for its
dateproperty in the YAML front matters; if it’s before the current time, then the file will be moved to the
_postsfolder for publishing
So what’s added / improved?
- The script automatically checks for the validity of the YAML front matters during each move of any post; among other things, it will add the following properties if absent:
- date: the last modified date of the file is used; this is useful if you don’t want to take the creation date for the draft as the date published on your website (which is the weird default behavior of Octopress) – in that case just leave this field blank and it will be added automatically when the draft gets moved to the queue (or when you put a file yourself into the queue)
postis assumed as the default layout, which should be sensible enough
- title: the file name of the post (subtracting the date prefix, if any) is used
What all these mean is that the minimal setup you’d need to have for a post is
- touch a new file in
_draftswith its file name as the title
- when finished, add
published: trueto the top (don’t forget the triple dashes)
- touch a new file anywhere with its file name as the title
- when finished, move it to
_queue; the file will then be published during the next update
The second approach eliminates the need to have the YAML front matters entirely
The script checks for all changes within the
git ls-files. This means compared to the approach in the original post, now the website will be rebuilt even when files like
Note that this might not be optimal if you’ve had
_draftstracked by git. In that case whenever a draft is changed or something gets moved into the queue then the source will be commited, changes pushed to the remote, website rebuilt and all. I myself have excluded these two directories from git because I don’t like the idea of having my drafts posting up to the cloud (I’m using GitHub as my host and I’m a little against having my unpolished thoughts shown in public) and I’ve had Dropbox versioning control these posts in the first place.
However, if you’re pointing your source to a private remote, then it might be a good idea for versioning control your drafts. In that case I’d recommend you change the script to auto-commit the changes in
_queuebut exclude website re-compiling in such cases by greping the output of
git ls-filesto see if all changes happen in these directories.
Where to download?
You can download the whole source file here. Below shows a preview of the code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74