The overhaul of my company and personal blog sites is now complete. It was long overdue, and my recent sabbatical presented a perfect opportunity to do a complete redesign and get up to date. I had been thinking for some time that I would like to switch to a simpler setup and workflow. After a great deal of research (the possiblities are seemingly endless!) I narrowed it down to a shortlist of two alternatives: Grav and Jekyll.

Grav is still a CMS, but simpler than Drupal which was my current solution. It does away with the database and stores content in the filesystem as flat files, written in Markdown. This has several advantages: it is well suited to the use of version control for site content, simplifies replication from development to production and makes it far simpler to take backups. It does this without sacrificing any of the UI sugar of Wordpress, Drupal, Joomla and the like. The disadvantage is that without a database Grav probably won't scale well and is unlikely to be suited to intensive enterprise applications. But for my purposes it looked like a good fit.

Jekyll takes this simplification even further. It isn't a CMS at all, but rather a suite of tools to build a static site from your Markdown files. This is appealing, generally I'm in favour of the KISS principle of choosing the simplest approach that satifies your requirements. But I started to see a snag: no CMS = no GUI. Jekyll simply uses a terminal, text editor and git repository. This is appealing to me on the desktop, but on mobile sounds like a convoluted headache. Blog posts I read of users jumping through hoops to post on the go using an iPad were off-putting. With Grav, I could simply connect to my home LAN via VPN and open the UI in a browser.

One thing was appealing about Jekyll, however. CMS generally speaking are a security vulnerability, as they present more attack vectors than a static site. Going static would reduce the threat of scripting and injection attacks. No database, no PHP, no worry that I'd overlooked a setting on production that would compromise security. Just Apache to worry about.

After a little thought and some more research I found a middle ground I was happy with: using wget to generate a static production site from Grav on dev. With the following command I can produce a static version of my site for upload to production.

wget --mirror --convert-links --adjust-extension --page-requisites --no-parent -e robots=off http://rassd.lan

It won't support Grav PHP plugins, but that's fine. If I decide in future I need the full grav features for my sites, I can simply switch to uploading the full-fat Grav site.