In my last post, I described my first look at tweaking the template and styling for my current blog platform, Scriptogram. This post I pick up on some of the anomalies I encountered and describe the building of a way to preview templates offline. I also outline some other problems I’ve encountered more recently.

In my last post, I described my first look at tweaking the template and styling for my current blog platform, Scriptogram. This post I pick up on some of the anomalies I encountered and describe the building of a way to preview templates offline. I also outline some other problems I’ve encountered more recently.

TL;DR

I wrote some code using Node.js and the packages Express, Marked, and Mustache, to preview a Scriptogram blog. You can find it on the preview-scriptogram Git repository.

Problem re-stated

The problem I’m trying to solve here, broadly, is the same one I outlined in my first post on creating a Scriptogram template. While Scriptogram gives you an HTML and CSS editor where you can tweak a theme and see the effect immediately, if you want to make more radical changes or build a template from scratch it can’t really help you. You only have to copy out the code you’re working on, back it up somewhere and cancel the changes if you’re midway through something.

Furthermore, you can’t edit both the HTML and CSS at the same time or version it. If you want to upload a new profile or cover image to try it out you have to do that outside the editor which means you can only try something new by doing it live.

Scriptogram doesn’t seem to be particularly well-supported and I won’t be using it forever. But while I am I thought it would be a good exercise to replicate what it does offline so that I can fiddle with my template, stylesheet and images more radically.

Replicating Scriptogram offline

In order to do this, I decided to create a temporary folder within my usual offline blogging workflow. Within this, I’ve put a folder called themes and within that a folder called basic. I copied the HTML and CSS from their respective editors in Scriptogram and put them, respectively, into files called main.html and style.css. This basically reflected Scriptogram’s own location of these files online as far as I could tell.

I then created a file that would allow for the rendering of the Scriptogram homepage based on these files. To do this I used Node.js and the Express middleware package available for it.

I started out by just seeing if I could fetch lists of the posts I’d created already from their respective folders.

As anyone who reads my blog will know, I split my post files into archives and drafts folders – the first for any posts that are already published to my blog, the latter for those I’m working on. Transition from latter to former is largely automated through my publishing script.

So the first thing I did was to see if I could lists from each folder to display.

When visiting the localhost rendering I would literally see a plain-text stringified-JSON view of the contents of my `archive` folder.

Once I’d established I could do this simple thing, I started work on representing the blog offline more seriously.

Last post, I described writing a script that would identify the essential variables which appear in Scriptogram’s HTML template and which I would need to give values for a successful preview.

The first step was fixing those which fell outside the post content. I created an object to include these.

{
	"author": "Guy Pursey",
	"title": "Coughing & Chopping",
	"blog_title": "A testing blog.",
	"posts": [],
	"base_url": "http://scriptogr.am/guypursey",
	"css": "<link href=\"/themes/basic/style.css\" rel=\"stylesheet\" type=\"text/css\" />",
	"profile_image": "http://www.gravatar.com/avatar/97e4c3c79d57e4e9df2f78aaa5c39361?d=mm&s=128",
	"cover_image": "",
	"accent_color": "",
	"theme": "basic",
	"pages": [
		{
			"permalink": "",
			"title": ""
		}
	],
	"page": "",
	"is_archive": false,
	"pagination": ""
}

Some I left without values but crucial ones like author and title I ensured had values.

This became the context object for the HTML template which I would combine with the Mustache templating engine.

I then wrote some code so that the content of each post was added to the posts array to be rendered appropriately with Marked.

Scriptogram anomalies

Last post, I mentioned that there were some odd things about the Scriptogram template.

Somehow, Scriptogram’s template replaces a double-braced content variable with functioning HTML rather than encoded HTML which is what Mustache double-braced variables normally give you.

Rather than change the variables to triple-braces directly in the template, only to have to potentially change them back again for use in Scriptogram, I added code to check for an array of variables to match to and replace double-braced instaces with triple-braced instances.

// Mustaches variables where doubled braces ought to be triplets.
var tripled_variables = ["css", "content", "profile_image"];

// Because Scriptogram only ever uses double-braced variables, replace these with triple-braced.
tripled_variables.forEach(function (v, i, a) {
	template = template.replace(new RegExp("\{\{(" + v + ")\}\}", "g"), "{{{$1}}}");
});

This ensures that posts display as fully rendered Markdown in the preview and not encoded HTML.

For some reason, Scriptogram’s template puts its braced variables into the CSS right up against closing braces. Although Scriptogram is able to cope with this, testing showed that vanilla Mustache does not.

// By inserting a space in each triplet of braces, this prevents an error with the CSS and Mustache template.
template = template.replace(/\}\}\}/g, "}} }");

This line of code simply separates the double brace at the end of Mustache variable from the closing brace of a CSS property and avoids an error.

Typeface issues

Scriptogram’s “basic” theme which I copied originally relies on a font called Proxima Nova. Using the font requires a license so my preview is not quite as accurate as I would like it to be. Hotlinking the font files hosted on Scriptogram itself would in any case cause cross-site scripting issues.

I need to look into font licensing further to resolve this.

What next?

Now that I’ve created a previewer, I can start to experiment and get down to the actual business of writing a theme.

However, my preview is still crude and could do with some work. There is the aforementioned font issue. And posts could be ordered. There are still several different views to consider, such as individual post, archive, and tag views. I could even separate archived posts from draft posts and allow for the ability to preview posts that have not yet been published. For now though, this is a quick and easy way to see the effect of changes on the homepage in an “offline mode”.