Moving to a Static Website, part 1: From WordPress to Hugo

I had been thinking about moving my blog from WordPress to a static site for a while. Today I give you the new Go backed blog.

This is a four-part blog post, the first covering why I moved to Hugo. Part two covers the hosting. Part three covers the Hugo deployment pipeline to Amazon S3. And the last part covers some of the benefits in terms of speed and security.

These posts are not intended as walkthrough on how to do it yourself, but simply sharing my experience hoping to impart some useful knowledge along the way.

WordPress is pretty easy to use, and there are plenty of plugins allowing you to do pretty much anything. However, the numerous WordPress upgrades and countless security flaws were making me feel it was time to abandon WordPress for a static site.

Nothing performs as good as a static site. Caching gets much easier, performance goes up, and are far more secure.

Static sites can be hosted anywhere, including GitHub Pages, Aerobatic, Amazon S3, Heroku, Google Cloud Storage, Surge, Netlify and more, and work well with CDNs. They run without dependencies on expensive runtimes like PHP and without dependencies on any databases. I’ve been using Digital Ocean Cloud hosting for the last 2 years. $5/mo is not that expensive, but solutions like GitHub Pages or Aerobatic are free and your site is hosted directly from your Git repositories, making it super easy to publish and work offline. Just edit, push, and your changes are live.

The static site generators

There are plenty of static site generators out there. Jekyll, Octopress, Hexo, etc. Check StaticGen for the top Open Source static site generators.

I wanted one that was easy to use and quick to compile the site for updates.

In the end, I have chosen Hugo.

Why Hugo?

Well, for two reasons:

1. It’s super fast.

2. It’s just a single executable with no external dependencies.

It’s written in Go and the installation is incredibly easy using Homebrew:

$ brew install hugo

I’m not against Ruby or JavaScript as languages. In fact I use JavaScript everyday at work. But I’m not a fan of having to setup and maintain all the Ruby gems or npm packages. Also, none of the other static site generators I tested could really compare with the speed of Hugo when it comes to building a site.

Migrating comments

The first step in this process was to migrate my comments to Disqus. It’s simply the simplest choice due to its ability to quickly integrate with WordPress and then continue to function on a static site.

I installed the WordPress Disqus Plugin, and it seamlessly integrated into my site and imported the comments into Disqus.

Importing posts

Now that all comments are secure on Disqus, the next step is to import the posts from WordPress.

This revealed to be by far the most challenging part of the process.

I tried two different tools – wordpress-to-hugo-exporter and Exitwp. While the rendered output from the former was good, the content of the Markdown files was mostly the same HTML used on WordPress posts. On the other hand, Exitwp’s generated files were pure Markdown, however the indentation was wrong, breaking the content rendering.

In the end I choose Exitwp simply because it was easier to format the Markdown files than cleanup the HTML mess generated by wordpress-to-hugo-exporter.

Importing WordPress posts into Hugo with Exitwp is a three steps task:

1. Export WordPress using the WordPress exporter under Tools –> Export in WordPress admin and place the XML file inside the wordpress-xml directory of Exitwp.

2. Run the converter by typing python exitwp.py in the console from the directory of Exitwp.

3. Copy the posts from Exitwp’s build/jekyll/<wordpress-site>/_posts to Hugo’s content/posts directory.

Worth it?

Setting up the new system was a bit more work than I expected, but I definitely think the effort was worthwhile.

I’m happy that I’m in complete control of the stack for my blog. Using WordPress always made me a bit scared – performance issues, database corruption, and security holes were always on my mind. Plus, I hated the idea of my content being stuck in a database somewhere.

I do most of my writing in Markdown or Asciidoc these days, so having my site content in one of those formats and versioned in a Git repository was the idea that most appealed to me. No matter what happens, I’ll always have easy access to that content.