My blog was gutted by spammers.
This has happened before, because I’m apparently not very good at keeping my
Wordpress installation up-to-date and secure. Only before, the spammers
who hacked into my blog to pepper ads in its innards only modified
PHP templates, and those weren’t too hard to fix.
This time, though, they came for the database.
Every revision of every post had random spam links injected into it. It
wouldn’t be very easy to fix. I wasn’t looking forward to seeing
what the spammers had in store for me next time, either.
So, I finally decided to take the plunge and convert my faithful,
oft-sullied Wordpress blog to static content.
Wordpress is great, but…
I’m going to miss Wordpress. Its admin UI is a shining example of
open-source design done really well. It has served me well
over the years and I appreciate how easy it made everything.
Unfortunately, though, its popularity also made it a target for
spammers to hack my blog, and my stubbornness at refusing to
switch to a hosted solution, combined with my delinquency at
keeping my own installation up-to-date, led to its demise in
The next step was to choose a static site generator to use.
I’ve had a fair amount of experience with Jekyll at work and, to
be honest, I was fairly underhelmed by it–though my expectations
for it as the “rolls royce of static site generators” probably
In short, these were my problems with Jekyll:
The Jekyll website boasts that one can
“Get up and running in seconds” by simply running
gem install jekyll bundler from the command-line.
This is patently false, at least for non-rubyists like me.
Every time I’ve tried it, I’ve gotten some error about how
my version of Ruby isn’t recent enough to run Jekyll. This
inevitably leads to me either attempting to install Jekyll in a Docker
container or trying to figure out which Ruby version manager to use.
Jekyll doesn’t actually watch all your files when it “watches”
them to rebuild your site. In fact, the first time I used Jekyll,
I edited its main configuration file, and was confused for a very
long time because my changes to it weren’t showing up when I
refreshed my browser. I eventually discovered Jekyll doesn’t watch that
configuration file for changes. This did not inspire a great deal of
confidence in the tool.
Jekyll is slow when it comes to larger sites. Granted, they recently
added incremental builds, but that isn’t very useful if you happen to
have a plugin that silently disables them. It’s also
not great if you’re in a situation where you can’t rely on an
incremental build cache to speed things up.
At first I wanted to try out Chris Krycho’s Lightning, because
I’ve been listening to his excellent New Rustacean podcast lately
and I’ve been enjoying learning Rust. But the README humbly
recommended that I stay away from it for now, and try Hugo instead.
This corroborated with the opinions of some coworkers who had used Hugo for
building the cloud.gov site, so I decided to give it a shot.
My new friend Hugo
After writing a hacky migration script to pull my Wordpress
data out of a really old 2014 dump of my database–er, it wasn’t actually
that old because I’ve only written two posts since then–and
settling on the hemingway2 theme, my newly content-transplanted
blog was ready.
And I like Hugo so far. It resolves all of the problems I had with Jekyll:
Because it’s written in Go, it has no dependencies. I just download
a single binary to my system and I’m ready to go.
It actually watches all my files, including the site’s base
configuration file, and rebuilds the site whenever anything changes.
And those rebuilds are really fast.
Granted, I’ve been using it for less than 24 hours, but it’s
left a very good impression so far. Much better than Jekyll did for its
What I’ll miss
As I mentioned earlier, I’ll miss WordPress.
I’m guessing I won’t miss its editing capabilities too much. Using
Hugo’s live development server with git for revision control and my
favorite text editor for Markdown-based posts feels quite nice,
at least for text-based content. I’m not so confident that it’ll be
as useful for images, as Wordpress’ built-in “upload an image and
immediately embed it in your blog post” flow is quite convenient,
but time will tell.
What I’m truly ambivalent about is the loss of comments. And by
“comments” I specifically mean comments that are owned by me, not
a third party like Disqus. Granted, I’d eventually disabled comments
on my Wordpress blog for reasons that ultimately pertained to my
own insecurity, but I was thinking of bringing them back. Sadly, it
seems that will be impossible now unless I cave in to a hosted solution
like Disqus. And even if I do that, there’s little chance that I’ll be
able to migrate over the existing comments from the Wordpress incarnation of
That said, I’m looking forward to my blog not being hacked by spammers
anymore. And even if it somehow is, at least it’s trivial to backup
and restore my blog’s content through git.