Eviscerated by Spammers - Toolness (original) (raw)

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 ofopen-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 mid-2017.

Choices, choices

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 didn’t help.

In short, these were my problems with Jekyll:

• The Jekyll website boasts that one can “Get up and running in _seconds_” by simply runninggem 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 first 24.

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 my blog.

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.