This year I used the winter break to move my website from an older Wordpress installation (always updated, but still getting stale) to a static site rendered with Jekyll. This move not only motivated by speed (environmental?) considerations and give me mind peace about breaking PHP plugins scripts in Wordpress, but also to use the transition to give it a bit more color and update the content. And have working blog again.

From Wordpress to Jekyll

I should have researched tools to help the content transition first. But I guess, I went for an explorative approach to see what Jekyll could actually do. Technology assessment, but going all in.

While Wordpress as a collection of PHP scripts works as an installation on a web server, Jekyll runs on my local computer and renders all files which are then uploaded to the web server. Wordpress is always there and, after logging in, I can create, edit and publish pages and posts. There is a huge amount of plugins to handle things like comments (never needed), publications (even wrote my own plugin) and lots of other things. This is convenient, but having such an installation live on a web server also means that it might get hacked or abused in other ways. Static site do nothing like this, there are not executable parts. Static sites are just files on a web server that are served to a browser, which is very fast.

Jekyll

The first thing to get started with Jekyll is installing the rendering system on my computer. I remember that I tried to install Jekyll earlier, but failed initially and quickly gave up. I’m still surprised how unintuitive the first steps are (update Ruby, install brew, …). Fast-forward a few coffees later. Once everything was running fine with an example site, I started to play with the functionality which tightly coupled to the local file and folder structure. This a common approach to many framework-like systems that have strong conventions and provide good defaults, if one chooses to obey the conventions to the letter. What people often overlook is the effort in learning about such conventions and structures, about the implicit assumptions that the framework creators had when building the system over time. With Jekyll (and other similar tools) this was relatively straight-forward.

I started with the minima layout and adjusted it towards the original layout and style of my existing Wordpress site. This involved copying a few stylesheets and moving them to SASS, a stylesheet pre-processor that allows to compile a single final stylesheet from different source (and variables, and more expressive syntax than plain CSS).

From Wordpress to Jekyll, now really

After the first parts of the website were ready, started to look for ways to transfer the content from the Wordpress site. Obviously, there is a Wordpress plugin for that. Not exactly for the latest version, but still good enough. After a backup of my Wordpress installation, just in case, the plugin quickly rendered a full Markdown-formatted export of all posts, pages and images. Zipped up, ready to go.

The export was very helpful to just drop the text content into my new Jekyll site folder. The linked images needed a bit of adjusting and relative linking. Essentially, global find-replace and some folder moving.

Colors and styles

I still like the blocky style of the website, but everything was soooo grey (could have been the Winter as well). So, I added color gradients to the main background blocks and the corresponding navigation buttons. In the past, one would have probably used background images, but it is quite easy to use CSS color gradients today. So I did that.

There are some more smaller changes to the layout and typography. For example, I incorporated the footer from the minima theme and adjusted its style to the existing typography. Also, the header (and the entire site) is now responsive. This was also something where SASS helped: my previous site had basically larger blocks of CSS copied and adjusted for different screen widths (via media queries). With SASS I could streamline this.

Speed

The previous site running on Wordpress was a bit unpredictable in the way how different plugins would add scripts and stylesheets to the HTML document. Of course, there are ways to compress this, but I never got around to it. The resulting site performance was not really good. Several files, smaller and bigger, had to be transferred to fully render a page. Typically around 200KB, which is not tragic, but too much in relation to the content. The new Jekyll site is much leaner, around 50KB. In addition to being smaller in size, all files are static and be transferred directly from the server. Wordpress sites require rendering of files, which can be improved by using a cache. Nevertheless, rendering requires access to database, the PHP scripting engine and all this takes time and power.

Now, it’s all good. The end.


Ok, this blog post would not be complete without the following picture; I guess I’m guilty.

blogging vs. blogging about blog engines