Migrating from WordPress to Jekyll – Part 1: Why I gave up on WordPress

migrating-from-wordpress-to-jekyll-part-one-why-i-gave-up-on-wordpress

This is a two parts post on why and how I migrated this blog to Jekyll. In this first part, I’ll mention the main reasons why I grew tired of WordPress and that led me to look for alternatives. I will publish over the next few days the second part with the “how” I migrated this blog from WordPress to Jekyll, with various useful tips I haven’t seen elsewhere.

UpdateHere‘s the new post on how to migrate to Jekyll. )

When I started this blog back in December, I didn’t really think I would be making very big changes to the code etc so soon… but here we are. I have completed just a few days ago a full migration of this blog to a different publishing system, and this very post is the first one I am publishing with it.

If you happen to be a regular reader of this blog, you may have noticed that I have kind of slowed down the publishing of new posts over the past couple of months. Besides some unexpected events that lately have forced me to more offline life than I am used to, there was something else that had to do with the blog but that in a way distracted me from writing new content: WordPress.

I originally planned to write a couple posts per week or so, since there’s a lot of topics I’d love to write about, and I’ve got so many notes about so many things that I would like to develop into useful blog posts. However, if for one I have realised it often takes much more time than I’d have thought to write a complete post on a certain subject, on the other hand I have been spending too much time on customising and fixing many aspects of WordPress, much more than I would like.

WordPress is a great CMS, and surely deserves the great success it has earned over the years compared to other competitors in the blogging arena; it has all the features a blogger would need out of the box, it is well designed from a SEO perspective and it’s so easy to add features thanks to a simple API and the zillions of plugins available. There’s also an infinite number of both free and premium themes available, and many hosting services are optimised for this particular CMS.

So for many reasons, WordPress really is a great choice for most people when it comes to content management systems designed for blogging. However, I realised pretty soon that while WordPress is certainly great for non-developers as well as for PHP developers, it is kind of overkill for me; plus, on the other hand, since I haven’t done any serious PHP coding in many years, I found quite frustrating how long it would take at times for me to fix or customise some aspects of the CMS the way I wanted.

Performance

In particular, I wasn’t happy with how difficult it could be to seriously optimise WordPress for performance. And by performance, I don’t mean the simple server side caching of pages, as some may assume since it’s a common topic on WordPress: for that there have been for years several valid plugins that can help speed things up by caching content to static pages, which can then be served much more quickly than pages dynamically built by PHP (on a side note, I don’t get why WordPress doesn’t have yet a caching-to-static feature built in as MovableType does). By performance, in this case, I mean client side performance more than anything else.

Sure, there are also plugins that can combine and minify JavaScript or CSS files, gzip pages in advance so that a web server like Nginx would not need to do the HTTP compression on the fly, and in some cases even further reduce the number of HTTP requests by using for example CSS sprites; in theory, there are plugins for all this and a lot more.

In reality, I bet I would have spent less time with a Rails app designed from the ground up to perform well, than extending and customising WordPress. Most of those plugins only work well if you have a really simple blog, with none or few other plugins; as soon as your blog uses several other plugins to improve some features built in WordPress or add new features, with these plugins also using JavaScript libraries, CSS stylesheets and so on, making those plugin work properly from a “client side performance” point of view can become a much harder task. It’s not uncommon, for example, for plugins to use libraries such as jQuery; the thing is that very often several plugins installed on the same blog require different versions of the library at the same time, without even checking first what scripts have already been ‘queued’ either by WordPress itself, the theme in use, or other plugins.

So from my experience with WordPress for my own blog, I found that optimising it for client side performance and faster rendering of the pages, often means spending too much time with fixing and tweaking both plugins and themes, rather than simply using, configuring or customising them (in theory, a plugin is supposed to be something kind of …ready to use for the most part, without necessarily having to fix or tweak the code – right?). Despite for the most part I can say I had achieved great results with WordPress also on this front, I really grew tired of how time consuming all this can be and just wished I had something else that would be easier to maintain and customise over time.

Bloat

WordPress really was overkill for me. It had so many things that were pretty useless to me either because I didn’t need them at all, or because I was using plugins that anyway replaced or improved features built in WordPress. Plus, as with any software, as it grows it also gets bigger, and not always in a positive way. I bet this is one of the reasons why many people have switched to something like Tumblr over the past few years.

So a lot of stuff in WordPress was basically bloat to me (I am well aware that “bloat” may mean something quite different from person to person). A lot of little things that I would not use but that would make my site heavier and slower to run. And as said I needed several plugins to make WordPress work the way I wanted; plugins often add to the bloat, and the more plugins you use, the slower and heavier your site will be – without taking caching into consideration.

Also, I’ve often seen overlapping in some features shared by different plugins as well as themes (for example in the context of SEO).

Upgrading and backward compatibility

WordPress is updated fairly often. That’s great, although this is more often than not because of security issues. Usually anyway having a site built on top of an application that is constantly updated is a good thing, right? The problem is, while with WordPress most upgrades are just a click away, in some cases it can be a nightmare to upgrade a blog since each time you’ve got to be worried with backward compatibility: will the new version work with your themes and plugins?

It would not be a big issue if WordPress were somehow more “stable”, where by stable I mean updated not too often; unfortunately there are frequent updates that just fix security issues and don’t add anything new or fix anything else. Of course you have to upgrade also in these cases, otherwise it may be possible for others to exploit some bug and gain access to your code and data, or worse. The problem is that regardless of the reasons behind an update, each time it could mean problems with regards to backward compatibility.

Poor security

As just mentioned, too often WordPress is updated just to fix security related issues. It’s not a secret that security has never been among WordPress’ best features; every now and then you hear of blogs being hacked or defaced, since not all bloggers have the ability or anyway possibility to keep their WordPress installs up to date so frequently, with the result that at any time there’s tons of sites in the blogosphere that run older versions of WordPress and therefore could be compromised sooner or later through some vulnerability.

Until literally a few days ago, just before completing the migration of this site away from WordPress, I was using a number of tricks to protect it, for example, from unauthorised access to the administration area, since that part of WordPress is the most common target of attacks and is often affected by vulnerabilities; also, WordPress out of the box doesn’t even do a basic thing like limiting the number of failed login attempts before banning a client.

Plugins can also be a significant risk: it’s great that you can so easily extend the CMS, but let’s face it: plugins are too often just crappy pieces of code with lots of holes. This is especially true for many of those plugins making use of AJAX, often leaving a blog open to XSS or XSRF vulnerabilities. A few months ago I tested a plugin (I can’t remember which one) that turned out to have some cryptic PHP code that actually rendered a sort of backdoor in the blog’s pages, allowing the plugin’s author to pass commands through the query string that would then be executed server side with PHP. I figured it out after noticing some weird, obfuscated HTML and JavaScript code in my pages, and luckily I found it right away, so it didn’t make its way to my production server. And this is more common than one would think. One would also assume that plugins downloaded from the official repository would be secure; well that plugin came from there as well as many others which have been found over the time to hide malicious code.

In a previous post on how to hide and protect WordPress’ administration by restricting access to known IP addresses, a reader reminded me that plugins should be allowed to execute the file admin-ajax.php within the wp-admin folder, for AJAX features. This means that with WordPress, still today, it is not even possible to completely isolate the administration area from clients, which would dramatically improve the security of a blog (provided that users are not required to login directly on the site, for example by outsourcing comments to Disqus or similar services).

All these issues concerning security, for a site that will then have to be cached to static pages to perform well, made me think: what is the point to have a dynamic CMS in the case of a blog? Wouldn’t it be easier to just have a static site instead? Especially if we take into consideration that the only case when a blog’s pages need rebuilding is when you publish or update posts (again, this is true if you are outsourcing comments).

Editing

I grew tired of WordPress’ editing UI, until I started to literally hate it. Yes, you can extend and customise it but at it’s core it’s buggy, doesn’t work well with some plugins and often screws up the HTML markup and requires you to manually fix it..

I was using a cool plugin for the syntax highlighting, named CodeColorer, which unfortunately didn’t work well with WordPress’ TinyMCE editor. It was a pain, in that I had to fix the HTML each time, for whatever reason, I needed to switch between the WYSIWYG interface and the HTML editor.

There are also some desktop clients I could have used, but I wasn’t attracted by any of them also because using these editors would have meant I had to give up on some other features added by plugins that would only work if I wrote posts with WordPress directly.

This made me wish I could just fire up TextMate, quickly edit my posts in markdown or textile, and then just push the changes with git to publish the new content…

Enter Jekyll…

I have been working almost exclusively with Ruby for a while now, therefore the next step naturally was for me to look for Ruby-based alternatives. I mentioned in a couple occasions that I had even started a sort of WordPress clone in Rails, so that I could more easily customise and maintain things over time than I would otherwise be able in PHP, for WordPress.

In the end I didn’t like too much the idea of a WordPress clone, so I looked for some existing Ruby solutions that would look simpler than that. I had already discarded the few Rails blogging engines out there since I didn’t like any of them for a reason or another, but fortunately I recently found a memo in my notes that reminded me about an open source Ruby project, Jekyll, that is actually quite popular in the Ruby community, so I finally checked it out.

Jekyll isn’t a full CMS like WordPress; it is actually not a CMS, but something a lot simpler, which I liked it right away, mainly for these reasons:

  • it is in Ruby, so that alone makes many things a lot easier for me
  • it is “a simple, blog aware, static site generator“, which is basically what I was trying to do with my Rails project (now obviously abandoned in favour of Jekyll, so that I could spend my free time on other side projects instead); I mentioned that, with WordPress, I used a plugin (namely WP-SuperCache) to cache the blog’s content to static pages; since I was already outsourcing comments to Disqus, the only time when my blog was actually changing was when I published or updated posts. Why not have a super fast static site in first place, then?
  • it uses liquid for the templating; I love liquid and have used it a lot in all my projects over the past few years, since it makes it really easy to manage even nested templates/layouts and I like both the designer friendly markup syntax and the possibility to easily extend it
  • I can just use git for the versioning of both code and raw posts!
  • posts are just markdown text files; the generated HTML is cleaner than that generated by WordPress, without funny escaping stuff. Having posts in plain text files rather than in a database, can also make it easier to export/convert posts to other formats if needed
  • I can use my favourite text editor, TextMate, which makes writing posts quicker (thanks to the markdown bundle) and with less distractions
  • improved security: with a fully static site (or almost, as I’ll explain in the next post), there’s nothing to worry in terms of security that concerns the application; as long as the server that hosts the site is properly configured and maintained from a security point of view, all the problems that you’d have with WordPress are simply gone. No dynamic app can beat a static site on security and performance
  • a static site is a lot lighter than WordPress. I always use Nginx as web server, since it’s super fast at serving static files; no need anymore for several PHP workers that suck memory and CPU; this means that servers and hosting can also be a lot cheaper for a high traffic site compared to the same site in WordPress
  • it’s very easy to customise since I can of course work directly on Jekyll’s source code; however, as we’ll see in the next post, there’s even an easier way to do this by using extensions which give you roughly the same power for the most part, but without requiring you to change Jekyll’s code directly
  • any hosting service supports Jekyll since it’s just static stuff; well I don’t need this since I run my own servers, but it is a good thing to know; I’ve seen many people even using Github Pages to serve their Jekyll-generated sites (since it is itself powered by Jekyll), besides for the source code hosting
  • deployment is as easy as copying files; you can for example generate the static site on your development machine and then use rsync to push changes to a production server; you could use git’s post-receive hooks, or, also, with rake or capistrano you can easily define custom publishing or deployment tasks, or for whatever other maintenance need – this is what I am doing now
  • Ruby developers can write plugins and extensions (we’ll see the difference in detail in the next post)
  • Jekyll does syntax highlighting out of the box with Pygments, so there is no need for plugins and alike for this
  • CSS and JavaScript files can also be processed with Liquid, so they can also include, for example, variables depending on the environment

Things that should also be taken into account regarding Jekyll

  • the blog’s content must be regenerated when adding or updating posts; while this is OK now since I don’t have many posts yet, I wonder how time consuming this task could become over the time
  • Jekyll can determine more accurately related posts for each post with an optional feature that however makes the whole process of generating the static site a lot slower; unfortunately, I am not too sure about the accuracy, either, compared to some plugins I have used for WordPress that -I think- did a better job on this front
  • as it is, Jekyll only understands dates for posts, but not times (although this is not difficult to fix); to be taken into account especially if you write multiple posts in a single day
  • while WordPress, with the right themes, is good enough from a SEO perspective, with Jekyll you have full control on the HTML markup of the pages and everything else; full control also means, though, that you need to be a bit more careful with how you write your layouts, otherwise your site’s SEO performance may be affected once you migrate from WordPress to Jekyll

All in all, I am very pleased with Jekyll so far. It did take a little longer than I’d have thought to migrate this blog as it is from WordPress, while also preserving the site’s SEO characteristics, but it didn’t take too long and I love the results.

I doubt I would ever want to look back! In the next post, I will describe all I had to do to migrate this blog from WordPress to Jekyll, with a few tips I haven’t seen elsewhere. So, if you too are planning to switch, as always stay tuned!




Have your say!

Please see my comment policy if this is your first time here or if you have any questions regarding comments.