Moving to Hugo

Since its inception, this blog has run on WordPress. I hosted it with a hosting provider, who gave me a dedicated VM on which I installed WordPress and the assorted tools, themes, and plugins to make it run how I wanted it to. And that was fine for several years. But times changed, and so did what I wanted in a blogging platform.

I was tired of the constant security vulnerabilities in WordPress, the patching, and the general tedium of maintaining the plugins and infrastructure. It wasn’t complex by any means, but it was more than I wanted to dedicate to what is a side project for me. With that in mind, I decided that a static site with a well-executed CI/CD pipeline for publishing is what I wanted.

After investigating several ways to export my current site into a static one using different tools, a good friend¹ recommended using Hugo.² He had just made a similar effort to re-do his site³ and even wrote an excellent article on the process. So, based on his article and other online documentation, including the official docs (well-written and comprehensive), I bravely headed down the path to moving my site.

I first needed to get all my existing content exported out of WordPress in a format that would make it relatively easy to put into the Hugo framework. This turned out to be facilitated by a plugin for WordPress called, fittingly enough, the WordPress-to-Hugo Exporter. The tool exported all my existing posts as markdown files inside directories, one per post. This made it easy to add those pages to my site, in my case, in an archive section.

The only caution I’ll use here is that the exporter was a bit of a nuisance to install. That may be because I hadn’t been in the server settings for WordPress or my site host in a long time. So, while it wasn’t the point-and-click installation that I would have liked, it was workable and did the intended job well.

Once I had those posts and other pages on my site downloaded and safely stored outside of WordPress, I was ready for the Hugo installation. This was as simple as running “brew install hugo” from a terminal. If you don’t have Brew installed or you’re not on a Mac, there are other ways to install it, all of which are documented in the Git repository for Hugo.

Once I installed Hugo, I created a new site by entering “hugo new site [sitename]” in a terminal window. This makes the directory structure you’ll need to begin development work on your site. All the files required are created except for your content. If you want to see what your site (at this point, a placeholder site that comes with Hugo) looks like, you can run a local webserver by typing “hugo server -D” in the terminal. Using the HugoPlate⁴ framework/theme, you can type “npm run dev” and accomplish the same thing. Namely, your website will be available for viewing locally at “localhost:1313.”

Once that was all accomplished, it came down to the nitty-gritty of editing markdown files, graphics, menus, theming, etc., on all of which there are plenty of resources to guide you. That part was the most tedious but the most rewarding as I began to see my site come to life. It was much easier than editing in WordPress to see the same results, at least if you’re doing it manually in the latter.

Once you have the site looking like you want it to, you can easily copy the contents directory somewhere (a container, a VM, a site host, whatever) and serve it up. This is probably the easiest thing to do, but I wanted to streamline a few things, so I did things differently. I used GitHub.

I created a new private repository in GitHub and uploaded my entire Hugo installation, which is not, strictly speaking, necessary. I wanted it there, however, in case I ever need to rebuild from scratch. I then enabled a feature called GitHub Pages and then created a new GitHub Action to publish my Hugo site. I could have made this pipeline on my own, but, as luck would have it, there was already a prebuilt action for Hugo.

I ran the Hugo GitHub Action for the first time, and my site was up and running on a GitHub domain. The only thing that remained was to add my custom domain and then repoint my DNS entries to the new host (GitHub). The best part of all this is that all I have to do to add a new blog post is check it into the repo from my laptop (or wherever), and the site automatically rebuilds the relevant files.

In the future, I may publish my site to a container on a cloud host like Digital Ocean, but for now, I’m happy with what I have. The only real reason I’d change is just for the sake of doing it. The performance of the GitHub-hosted site is more than adequate for my humble blog. But, sometimes, I can’t leave well enough alone so we’ll see how long I stay content with what I have.

I’d like to add a final thanks to Tony Mattke over at RouterJockey.com for the inspiration and the helpful pointers along the way. Without his help, the whole thing would have been a bit more challenging. I like a challenge, to be sure, but sometimes, hitting the easy button is the way to go.