I have left this site to the abyss of unvisited websites for the past four years, getting occasional e-mails from Wordpress that the CSM updated automatically due to security reasons.
After a friend mentioned there’s something wrong with the theme I was using, I’ve decided to do something about it. The theme itself wasn’t updated for months and wasn’t compatible with the backend anymore. I’ve switched the site to a plain and generic 201X theme as a stop-gap measure, and resolved to revive the blog, to save it from a limbo.
Static generation
Ever since I’ve heard of them I liked the idea of static site generators. In the gist, common blogs and websites host a suite of scripts that on-the-go look up content, dress it in pretty colors and shapes already in the user’s browser. While fabulously versatile and powerful, it has it’s issues.
For one, it’s common in dynamic websites to weigh tens megabytes or more for plain text blogs, and take ages to load even on decent hardware with broadband Internet connection.1
Another is security - scripts get hijacked, admin passwords brute-forced, a database injected to. All the complexity that facilitates the feature list also provides avenues for a breach. Good on Wordpress for forcing security point updates on the user even if they’ve forgotten their site exists.
Back on point, I’ve liked static site generators as an idea enough to start writing one myself. It didn’t go far, and a big part of that was my misunderstanding of how templating should work. I’ve also tried to code it all by myself, and it’s an easy way to burn yourself out.2
Static site generators go back to the roots of web development, where you had to imperatively place every 256-colored rotating flaming skull GIF using HTML tags or with a WYSIWYG editor. Now, you declare your content with a markdown language of your choice, and the generator processes that one-time into HTML and CSS bundle you can hook up to a HTTP server and forget about. Simple, clean and efficient.
Hugo
These days, if you throw a metaphorical rock (or a literal google search) in any direction you’ll probably hit a static site generator. You’ll find at least one written in any popular web language and then some.
After little research I went with Hugo3, self-proclaimed fastest of the bunch. While I wont care about speed of site building for a while now (12 blog entries and one static about page is microscopic on a blog scale), it also offers decent docs and seemed easy enough to get into.
I’ve started the migration in Oct 2017, and most of the work was also the easiest part (80/20 rule, right). Using a script4, I’ve exported my Wordpress posts to a hugo-friendly format, spent a day cleaning them up, and then couple of hours on deployment automation (so I don’t have to manually copy the generated files over to my server via SFTP or something similarly barbaric). For that I settled with a simple setup of ssh and git hooks5, which in hindsight is the only way I could do it. I decided that my knee-jerk reaction of using travis-ci with docker to build a 60kB website is like driving a semi-truck on a 20 minute commute every other week. A waste of resources.
The harder 20% I predictably spent dealing with details, and I’ll tinker with it still.
Conclusions
There’s still some issues I want to deal with, like writing my own theme, doing away with any Google Font links, perhaps adding a table of content for the post. In the end though, it depends on my activity with the blog itself, and my ambition is to get at least one post in every couple of weeks or so. I keep working on interesting (and I like believe, not only to me) projects, and the simplest post for me would be a work journal. We’ll see.
In the end, at least there’s no admin panel to brute-force into anymore.
MW