Kirby CMS Migration

You may have noticed a lack of new posts on Sparsebundle over the last few days. I’ve been working on migrating the site over from Pelican, a Python-based CMS to Kirby, a PHP-based one.

Kirby, in addition to being PHP, is also a flat-file CMS. It reads text files written in Markdown similar to how Pelican does. Unlike Pelican, Kirby does this constantly instead of having to trigger the changes via a shell script or cron.

Whilst Pelican does feature an option to automatically update with any new changes, I’ve found it simply doesn’t work as I expect. If I want to remove something, it doesn’t do it. What I have had to use instead is a cron that runs every 15 minutes which deletes the output folder and rebuilds it. For those few seconds, my site is down – every 15 minutes. But once the site is generated, it’s 100% static HTML so there’s pretty much no overhead. Kirby, no matter how small, will have slightly more overhead due it being PHP1.

As much as I like Pelican, I find it a bit convoluted to maintain, in addition to the issue above. I like to tweak the style of my site from time to time and whenever I want to make and test a change I have to rebuild my local version, since Pelican generates static HTML and serves that to visitors.

Templates are stored separately and used only the HTML is built. This means that if I want to, say, change the text size, I have to edit the template outside of the site build, rebuild the site and only then can I see the change. With Kirby, I can edit the template files just like any other CMS and see the results instantly. When you’re making incremental changes, this gets quite tiresome, especially when it takes my Mac a good 10-12 seconds to rebuild my local Pelican site.

With Kirby, I can instantly see any changes and the code is just much more familiar, not to mention far less complicated. Perhaps the best part of it is that I can take the entire Kirby folder and move it to any server and within 30 seconds, have it up and running.

There were a couple of downsides to the migration, mainly due to Kirby’s requirement of each post requiring it’s own folder and each text file being of the same name. It adds maybe a second or two to how I post but I can’t really complain2.

I also had to edit the text files for my posts because Kirby insists on using Text: before the content as well as including dashes between each of the blog attributes, such as date and tag. I’m sure if I modified the core of the CMS I could change this behaviour but I’d prefer not to since it would cause upgrade nightmares and Kirby 2 is just around the corner. Instead, a bit of time with regular expression and some old fashioned find and replace sorted that out.

Reconfiguring my Dropbox syncing was simply a case of creating a new symbolic link to Kirby’s content folder on the server, meaning I don’t lose my favourite method of updating posts.

Overall, I’m much happier with Kirby. There’s very little to learn between and some of the issues I’ve run in to will likely be resolved by spending a little more time on the already excellent support forum.

  1. I’ve noticed a slight increase in CPU usage on my server since deploying Kirby, yet considering the only usage it was getting previously was when Pelican was regenerating the site every 15 minutes, that’s to be expected. 

  2. My one concern is that Byword on iOS can’t create new folders, meaning posting on the go might be a little more involved than I had previously set up with Pelican.