Deanacus

by Dean Harris

Moving From Wordpress To Jekyll

I’ve been blogging for a number of years now. Since around about 20051, I believe. In that time I’ve used Blogger, Wordpress.com, ExpressionEngine, self-hosted Wordpress, and Tumblr. Now I’ve got another tool to add to that list – Jekyll.

When I first started this site at the beginning of this year, I had fully intended on running it on something, anything, other than Wordpress. Unfortunately that just wasn’t meant to be, and as time ran out before my arbitrarily selected launch day I ended up going back to what I knew and built it on Wordpress. I’ve finally gotten around to spending some time with Jekyll, and have been able to get rid of Wordpress.

Rebuilding a site on a new platform can be a lot of work. With that in mind, I thought I’d take some time out to engage in a bit of navel gazing and go through some of the things I’ve done to get this site up and running.

Why Jekyll?

What Is Jekyll?

To get an idea of what Jekyll is, it’s probably best to turn to the project’s Github page:

Jekyll is a simple, blog aware, static site generator. It takes a template directory (representing the raw form of a website), runs it through Textile or Markdown and Liquid converters, and spits out a complete, static website suitable for serving with Apache or your favourite web server.

Essentially, it traverses a file structure (either local or remote) comprised of HTML, CSS, JS, Markdown, and XML2 files to spit out a static HTML website. What this means is that you get some of the best aspects of a dynamic site – separation of content from presentation, automated page generation, and templates – with none of the drawbacks – databases, security issues, software updates, bad code.

It’s also damned fast. Ignoring things like CDNs and other high level (and high cost) caching mechanisms, you’d be hard pressed to beat the rendering speed of a static HTML file.

Command Line

Jekyll is run from the command line. Basically this means that you get to feel like a bad-ass hacker when you build your site. It is an indescribably nerdy feeling to fire up the command line and build and deploy a blog with just a few commands.

Local Blogging

One benefit that I hadn’t considered until I started playing around with Jekyll was the fact that all of my files are stored locally. That means that I can edit them anywhere that I can take my computer to. It doesn’t matter if I’m in a plane at 30,000 feet, or if I’m at home with a speedy WiFi connection, I can write a blog post, and build a perfectly working version of my site with or without an internet connection.

Why Ditch Wordpress?

Wordpress has served me fairly well in the few years that I’ve been using it. It hasn’t been a perfect relationship, but there haven’t been any significant problems. I did have a few growing concerns, namely the lack of any caching by default, the frequent updates to both the software itself and associated plugins and themes, and most particularly the changing focus from simple blogging engine to full featured CMS. Really, though, it just became clear to me that Wordpress wasn’t the right tool for me.

Automation

Once I’d gotten comfortable with using Jekyll via the command line, I figured I’d spend a little time automating the whole process. Rather than using something like Rake, I thought it might be fun to use my app launcher of choice – Alfred.

The Alfred Power Pack has a feature lets you create “Shell scripts” that be as rudimentary as a set of daisy-chained terminal commands. You can even set them up to receive parameters from Alfred.

So that’s exactly what I did. I set up four terribly written scripts to take care of the important tasks - clean, build, deploy, and new post.

Clean

Clean takes care of deleting the existing version of the built site. It isn’t really a necessity, but it allows me to delete any files created in previous builds that really shouldn’t be there.

rm -rf ~/sites/jekyll/_site/*

Build

Build takes care of generating the site from the source files. Because Jekyll ignores files starting with a dot by default, I’ve added a line to include the .htaccess file as well.

cd ~/sites/jekyll
jekyll
cp .htaccess _site/.htaccess

Deploy

Deploy combines Clean and Build and then uploads the generated site to my webserver via rsync over SSH.

rm -rf ~/sites/jekyll/_site/*
cd ~/sites/jekyll
jekyll
cp .htaccess _site/.htaccess
rsync -avz --delete /users/username/sites/jekyll/_site/ ssh username@hostname:path/to/site/

New post

Newpost takes care of file creation for new post files. I copy my draft, including the required YAML front matter then trigger this one. I pass it a parameter (the {query} bits) in the form of a post slug and it then creates a new file in the right directory, with the right file name. The post then gets opened up in Byword for a final check before publishing.

It still needs some work, I think, but it works for now.

cd ~/sites/jekyll/_posts
pbpaste >> $(date +%Y-%m-%d)-{query}.md
open -a byword $(date +%Y-%m-%d)-{query}.md

Redirection

I made a few key decisions about URLs and old posts fairly early on in the build process. I decided that I was going to simplify my URL structure, from date based to /article/permalink. I also wasn’t going to be bringing all of my old posts over to the new site, but rather creating a mirror of the old site at archive.deanacus.com. Finally, due to the fact that I wanted to offer multiple subscription options, I was going to be moving the location of the RSS feed.

These decisions were not without their problems, though. I didn’t want to have visitors end up at a 404 page when they followed a link to a post here, nor did I want to lose all of my RSS readers. So I did the only thing I could. I wrote a .htaccess file.

I know next to nothing about .htaccess files so it was quite a painful process, and was by far the most time consuming part of the job. In the end, though, after much googling and testing I think I managed to get it right.

Still to do

There are still a couple of things I want to get done before I can finally call this implementation complete.

Include Raw Markdown

I think it would be kind of cool to be able to see the raw Markdown files for each and every post and page on this site. How that would be possible I’m not quite sure, but I’m hoping to find a way to work it out.

I have a feeling it will involve using the Jekyll Postfiles plugin by Andre Arko, and tweaking my Newpost script to automatically include the file.

Fix Newpost Script

As it stands, the Newpost script requires that my draft include the YAML front matter, and that the parameter I pass to it be a slug, rather than a post title. I’d like to adjust this so that it can generate the front matter for me (trivial) and so I can pass either just a title and have it generate a slug, or pass both a title and a slug to it (non-trivial). If I can get that worked out, then I’ll be damned satisfied with that script.

Footnotes

  1. Most of which has been lost, thankfully, to the mists of time.

  2. If you want to have a RSS feed, that is.