Thoughts on Migrating from Wordpress to Jekyll

Over the past week, I have converted my blog from Wordpress to the static site generator Jekyll, written in Ruby. I have also merged my blog at Informed Skeptic to my personal home page. This post talks about this transition -- why I did it, what are the benefits and pitfalls of using static sites, and some miscellaneous other thoughts

Why leave Wordpress?

Wordpress is a modern and quite-extensible piece of blogging software. It has served me well over the past two years for my current blog, and I also used it years ago for a different blog that is no longer online. Among full-featured blogging platforms, it reigns supreme.

Unfortunately, the popularity of the platform has also encouraged feature-creep. Wordpress, even with caching, is remarkably sluggish. This is particularly true for the administrative panel, where it can take 2 minutes of wasted time just to get access to the blog post editor (not to mention that every time I log in, there is always a plugin to update which adds to the administrative time of the system). Part of the success of Tumblr has been its focus on reducing posting time, since delays almost always discourage users from writing updates. I finally decided that I wanted a faster platform.

The other concern I had was security. Wordpress' popularity encourages more attacks, and I am not at all convinced that the system is written in a secure way (for instance, Wordpress allows infinite login attempts on the administrative panel). Part of this will be true for any dynamic web application, but I felt there must be some alternative that allows me greater performance with less interface sugar while also increasing the general security of the system.

Discovering static site generators

Many of my friends and several engineers I follow on the web have turned to Jekyll to solve their blogging software complaints (Jekyll is also used on the backend for GitHub Pages). The benefits of static site generators are numerous:

Performance is great. Since all pages are just static HTML files, files are rendered as fast as you can send them from the server.
You have greater control of your blogging environment. I can choose to have entirely different themes for different parts of my website, which I like for some of the larger writing projects I will be posting in the coming weeks.
All posts are written in Markdown (or some other text markup language). This means that my writing is more portable, and will make it much easier to change software in the future if I choose to do so.
Versioning is easy. You can use git to version your website, which means that you can save incremental versions of all of your writing and code without worrying about making an irrevocable change.

However, there are some serious downsides to consider:

Plugin support and many dynamic features like comments are not easily available. I philosophically disagree with allowing a third-party (Disqus, Facebook, etc.) control my comments. Part of serving my own blog is to remain in complete control of its content at all times. I don't want to find out that these companies have been bought out and I suddenly have to migrate my data. Yet, without such a third-party provider, hosting comments is challenging. I ended up deciding that comments were not a crucial feature.
Static site generators take quite some time to compile. There is something to be said for making a quick change to a page and having it immediately be viewable to the world. Because I use Related Posts, compile time for just the 100 posts I have in this system can easily take several minutes. I don't think this is unacceptable, but it definitely feels like a retrograde improvement.
Syncing files is a bit of a chore. You can script this to be automatic, but you still have to verify that the syncing worked correctly.

With all of this in mind, I had to actually choose the software that would generate the pages. Jekyll is by far the most popular in this category, but I was worried about writing in Ruby (I come from Python, and while the two are quite similar, I didn't really want to dive into Ruby just for my blog). There are some nicer forks of Jekyll such as OctoPress, however, I found that there were quite a few bugs that got added in these forks that I didn't want to deal with.

On the Python side, the main contender was Hyde, which creatively represents the Jekyll of Python. However, I found the Hyde project to be quite diffuse and disorganized -- there are several different versions of Hyde, and I felt that none of the software was going to be sustained in the long run.

I obviously chose Jekyll in the end, and ended up relearning some Ruby along the way.

Converting from Wordpress to Jekyll

The transition process was not too smooth, unfortunately. Part of giving up the simplicity and "it just works" of Wordpress is that many things you might want to do with your blogging software you probably have to write by hand. For instance, I wanted a single page of all the tags that I use in my posts so that readers can find similar content easily. I couldn't find a plugin that did this, so I ended up having to write the Ruby code myself. Certainly, a willingness to hack at Jekyll is required.

I found that this really long post on migrating to Jekyll from Wordpress was invaluable. I used a variant of the author's migration script to get my posts out of Wordpress, although there were quite a few encoding errors that had to be handled manually

The biggest issue by far with the process though was the lack of documentation (isn't it always?). I suppose that this is to be expected with a project aimed at bleeding-edge engineers, but still, Jekyll has been in the wild now for quite some time, and a decent set of API documents would be significantly helpful. Some of my frustration no doubt comes from my lack of experience with Ruby, but a large proportion can certainly be blamed on the almost random nature of the docs. All the information is there, it just can be really hard to find sometimes.

Conclusion

Altogether, I am happy with the transition, even if it took 3-4 days longer than expected. There are still some kinks in the system to work out, but I think that the new blog that came out of the process is qualitatively superior to my old Wordpress blog. And with any luck, updates will happen more frequently now that it is easier to do so (or so I tell myself).