After my last post on writing a script for previewing Scriptogram blog posts before they go live, I realised I had based it on my blogging workflow without much context or explanation. I’ve since labelled my blogging workflow
ahem – out of a desire for a short name, that might one day be used as a command and that connects with my current blog’s name (“Coughing & Chopping”; explanation forthcoming).
So this post is less about the creation of a preview script that integrates with
ahem which I have already inadvertantly created, and more about adapting that script to work with a “vanilla” use of Scriptogram.
My blogging workflow scripts, now stored under the
ahem repository, rely on
drafts folders for published and unpublished posts respectively. In either case, the conventions of that workflow require each post to have its own folder. Each post’s folder contains the Markdown file of the post itself, the date in a separate text file, and any tags in another separate text file. This way, metadata about the post is kept with the content without actually disrupting the content itself.
On publishing to Scriptogram this information is then pulled together into one post request so that the header is extracted from the main file and put together with the date and tags to form a metadata header at the top of the post.
If you’re familiar with Scriptogram, you already know that it expects its metadata header like this:
Title: Vanilla vs `ahem` Date: 2015-05-25 21:52 Tags: scriptogram, preview, ahem, blogging, workflow
I based my
preview-scriptogram code at v0.0.1 on my
ahem workflow, where metadata is separated, without explicitly stating so. I need a way to offer a more vanilla option if the code is to be more widely useful.
preview-scriptogram repository contains a file called
setup.js. This can be run with Node.js to create a
config.json where one can then add the locations of one’s
drafts files if using
ahem. Having a location for
drafts would still be relevant for a more vanilla use of Scriptogram, but the way the files are handled would be different.
In my current script, the location of each file is found by checking each folder in the “archives” folder and assuming the name of the main file is the same: that is,
archive_location + v + "/" + v + ".md" where
v is the name of each folder/file.
For a vanilla Scriptogram, one might instead simply want to preview the posts under
Apps on Dropbox where the real Scriptogram picks up content to feature on the blog. And in doing so one would want to parse the files as Scriptogram conventionally reads them rather than as I have them in my
So my updated
preview-scriptogram code contains two separate functions
ahem_fn. If one is pointing at a folder where all the posts sit together with their metadata in them (for example, the actual Scriptogram
posts folder on Dropbox), one can run the script as is. If one wants to use it, as I do, with the
ahem workflow, one can point the
archives folder at that type of folder and, in
config.json, declare the property
ahem to be
setup.js so that it automatically creates an
ahem property in the config object, but as
false so that the vanilla function is still the default one.
The code itself could probably do with some refactoring. But having access to a preview of
drafts should probaly come first. Also, I want to press on with creating a new template and seeing how that goes with my previewer.