Netlify, Hugo, and Wowchemy or: How I Learned to Stop Worrying and Love the Blog
The Blog Post About Moving the Blog
For years my blog was on WordPress hosted by a third party, I recently moved it to Netlify, Hugo, and Wowchemy. It is much faster, easier to work with, more reliable, and more secure. Getting a blog up and running with those tools is very easy; migrating hundreds of posts, less so, but worth it.
It feels like a software blogger tradition to write a blog post about the blogging tools they are using. I’ve read quite a few about bespoke, very complicated solutions that wire together disparate storage mechanisms, parsing tools, more storage, one or more cloud, processing tools, CDNs, and whatever else can be fitted in.
I am a strong believer in off-the-shelf solutions, or better yet, services I can buy that do it all for me.
Eight years ago, I started using the blogging platform that my domain registrar gave for free, it was simple but had many limitations that would not suit a dev blog. I quickly switched to WordPress hosted by a web hosting company, I used this for my blog and podcast until mid-May 2011, when I made the switch to Netlify, Hugo, and Wowchemy.
Starting at the end
Thanks to a conversation with a friend, I was introduced to Netlify, it has a simple to use UI and integrates with Hugo and GitHub so easily that you can have a site/blog up on the web, and public in about five minutes (no exaggeration).
Hugo was my static site generator of choice after playing around with it and Jekyll. For me, Hugo was easier to get started with and the available themes suited me better.
The Wowchemy theme is clean and full of features. It takes a little bit of time to get used to but once you, it’s great.
It was very easy to integrate Disqus and Google Analytics into the site.
Netlify makes it simple to preview changes to your site by deploying a preview of the site for every PR to your main/master branch. That preview site can be shared with interested parties, or as in my case, used to make sure the changes I’m making work as expected.
Making a change to my site is now simple for me -
- git push changes
- git pr create
- review preview site
- git pr merge
- main site deployed
I love working with this combination of tools. It’s easy, fast, and robust. Even though the site has been live for less than I month, I’ve been using working on the site for a few months and never had a problem.
The WordPress Years
When I started using WordPress I was new to blogging and was not sure I wanted to keep at it. I found a reputable hosting company and set up my site there. It turned out that that company was not very good and the site barely functioned. I moved to another reputable hosting company.
The second company was generally fine, the servers were a bit slow, but I was on a low-cost tier, about $10 a month. There were also some oddities like the lack of proper SSL certs for the site unless you paid a significant amount to have one generated/installed, but there was a workaround that involved some WordPress plugin that did some address rewriting or something, I can’t remember. But like all workarounds, you pay for it later, and I did when the hosting company started to offer free SSL - I had to undo a lot of links inside the posts.
There were frequent plugin updates, but these were often quickly revised due to bugs or incompatibilities. It was always better to wait a couple of weeks after an update came out before installing it.
Plugins often have security vulnerabilities, so you need a plugin to monitor your plugins, but as I mentioned you can’t just let the plugins update themselves whenever they want to because they might take your site down when you are not looking.
Themes also have vulnerabilities, but not every theme is maintained. Many were created by people for their own needs, shared with the community, and never updated again. Now you have to manage security vulnerabilities in a theme you didn’t create, probably don’t fully understand, and have little interest in working on.
There were the less frequent WordPress updates, I generally stayed a couple of versions behind the latest. These included major and minor updates, with the major ones often involving a database update. Those updates too can go wrong, but luckily never did for me.
Then there is the PHP version, you must keep an eye on that too, but of course, you don’t move to the newest because there is a long history of PHP updates breaking themes and plugins.
You need to take care of backing up your site, there are some automatic tools out there and I used them to send backups to my google drive, but I never had to do a restore so I don’t know if they worked, so much was dependent on the domain name that it’s not trivial to test a backup.
I also used a plugin that lets you migrate your WordPress site from one hosting company to another. This did work, I know because I set up xampp and WordPress locally on my laptop, restored the site, and with some fiddling got it working. So even if the site went down, I had the content, that was good.
If this sounds excessive to you, remember this is almost eight years of blogs and podcasts, admittedly the podcast itself is hosted by another service, but the accompanying website was on a WordPress instance with the hosting company I’m talking about here, and they don’t do backups of their servers. Most of the blogs have a zip with fully working source code that I’m sure I don’t have elsewhere in many cases.
Backups and reliability were important to me, and that is where the story turns…
The Plugin Update that Brought the Site Down
Doing one of my standard updates to a plugin, I think it was the security one mentioned above, something went wrong, and the site went down. The database couldn’t be reached, the site could not be served, the admin dashboard was unavailable.
I called the hosting company support, in the early years their support was great, they knew WordPress, they knew security, could help with
.htaccess files, database permission issues, everything, but by the time this happened, it was hit or miss, sometimes the person was helpful, sometimes not. Luckily this time they were, a PHP process on the host had gotten stuck and was consuming all available resources. The tech support person killed it and the site came back up.
But this was a bad sign, on top of everything else that could go wrong, a bad update to a plugin could kill the site. I had already researched the tools I would use if I built a new site, I knew it would be Hugo and Netlify, the day after the site went down, I started work on migrating 140-ish blog posts and 150-ish podcast posts to markdown.
The Great Migration
WordPress lets you export your site to XML, but when I used it it didn’t bring everything with it, most images and zips didn’t come down.
There are a few tools that convert the XML to markdown, and they mostly work but needed some tweaks. Once those were in place I generated a markdown file for every post, but these were missing the images and zips. I wrote a tool in C# to read the markdown files, grab the links, pull them from the live site, save them beside the markdown and fix any references. This took a while to get right.
Migrating the posts for the podcast was a little easier, with fewer links and images to deal with.
Once this was done, I started on the new Hugo site.
Hugo and Wowchemy
After finding the Wowchemy theme, working with it was easy, aside from some specific things around code highlighting and line numbering.
Hugo and Netlify have a few peculiarities around the characters that can be in URLs and tags, specifically “#” and “.”, a little experimenting and it was fine.
Add in the Disqus handle, they offer ad-free accounts to bloggers, and the google analytics id, and I was nearly done. I still had a few pages to add, and I wanted to check that the URLs on this new site matched the URLs on the old site, so a bit more to do.
Testing the site locally is very easy with the Hugo server, no xampp, Apache, IIS, database, or complex configuration. Run the Hugo command in the directory where the site resides, and it starts up in a couple of seconds on localhost.
The site, my posts, and zips were in a GitHub repository, no need to worry about backups.
Netlify combined with Hugo, Wowchemy, and GitHub is amazingly easy to work with. The Wowchemy theme comes with a Netlify configuration file that sets up everything you need to build and deploy on Netlify.
I granted Netlify access to the GitHub repository where my site is stored, in a matter of seconds Netlify is building the Hugo site and deploying to a random Netlify URL they generate, and then I can see my site up and running on the web.
Down Goes the Old Site Again
Just as the Netlify version of the blog and podcast were up and running, the company hosting the WordPress site informed me that the physical computer my sites were on was at its end of life, and my sites would be migrated to a new server, and that nothing will go wrong. I had my doubts…
I kept an eye on my sites and they seemed fine, then I got an email saying that my site had been moved. When I tried to access my blog, it took about 15 seconds to load the homepage, subsequent page loads took 2-3 seconds. I called, they said the while other sites were being moved the server was under significant load and that this might go on for a couple more days. I pointed that they should have made the move in a way that didn’t have such a detrimental impact, they agreed that they should have, but it was too late now. A few days later the site was no better, I called and the issue was escalated, but to no avail.
It was time to make the switch to Netlify.
The DNS Change
Changing the nameservers on my DNS registrar from the old hosting company to Netlify was the last step in the move.
I followed the instructions and put all the DNS records on Netlify first, including CNAME and email records.
Over on my DNS registrar, I replaced the nameservers of the old hosting company with the Netlify ones. Within a couple of minutes, Netlify was serving the blog and podcast on the right URLs.
Over the next few hours, Netlify generated SSL certificates for each of the sites, and that was it, serving on the correct URLs, with HTTPS, emails forwarding correctly. Done!
The sites load far faster than before.
There are no plugin/theme/PHP/WordPress vulnerabilities to worry about, no maintenance whatsoever.
Working with it is very easy. Tweaking the layout of the sites, while not trivial, is far easier than altering a PHP theme.
Backups are not an issue, I have the GitHub commit log.
And I’m not worried that the sites will go down, Netlify monitor and maintain their systems around the clock.
- GitHub Actions with .NET, Part 5 - Build a .NET Application and Upload to S3
- GitHub Actions with .NET, Part 4 - Building an S3 bucket with Pulumi
- GitHub Actions with .NET, Part 3 - Manual Approvals
- GitHub Actions with .NET, Part 2 - Dependent Jobs
- GitHub Actions with .NET, Part 1 - Hello World and Downloading the Artifact