Why I switched from WordPress to Jekyll
why I switched from WordPress to Jekyll
Performance
Bloat
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
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
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 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.
Enter Jekyll…
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!