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

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.

The problem

My blogging workflow scripts, now stored under the ahem repository, rely on archives and 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.

The solution

My 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 archives and drafts files if using ahem. Having a location for archives and 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 ahem workflow.

So my updated preview-scriptogram code contains two separate functions vanilla_fn and 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 true.

I’ve modified 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.

What next?

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.