The WordPress years

This blog was originally hosted using WordPress, the famous CMS. It was quite an active site at the beginning, with a post every 2 months on average.

But then, the contribution rate dropped, and the blog began to be only used to relate the results of our yearly hackathon. As the site was a bit deserted, we forgot to update it, which is quite a fatal mistake when dealing with a WordPress site…

The next part of the story was inevitable: not updated, the site was vulnerable to attacks, and we got hacked. Luckily, the hackers were quite the funny and harmless type: instead of deleting our articles, or try to hijack the server, they edited the content of all our posts to insert links to external sites. And strangely enough, the links did not point to some offensive site, but to a website selling some inflatable bouncing houses and slides.

But this was only the beginning of the downward spiral: before we could realize that we had been hacked, the site was impacted by the fire of the datacenter hosting it. To cap it all, the backup of the site was also hosted on the same datacenter, and so it burned at the same time !

We had some old and incomplete backups of the WordPress files and database, and also the version archived by The Wayback Machine site .

We could have reinstalled a newer version of WordPress, and recreate the site. But the hacking we experienced, and the fact that using a WordPress site implies constant updates and security monitoring made us consider using other tools.

Going Static

After all, this technical blog was mainly written by people using git all day long ; why not try to find a solution allowing us to have a version control of the posts, so we wouldn’t have to worry about a single point of failure regarding the updates ? Besides, considering the content of the site, we did not need all the fancy plugins WordPress can offer: we had no tracking, no shopping module, no complicated social network integration… So why don’t use a static website generator ? There are many of great tools available, but we long wanted to test one of them, the self-named “World’s fastest framework for building websites”, Hugo .

Installation

Hugo is quite easy to install, as it is packaged in most Linux distributions. A simple

$ sudo dnf install hugo

is enough on Fedora, Red Hat and CentOS, and

$ sudo apt-get install hugo

on Debian and Ubuntu.

To boostrap a site, we only have to launch the command

$ hugo new site <name>

After adding a new post as a markdown .md file in the content/posts, we can see this post by running a local server (here the -D argument allows displaying even draft posts, that would be hidden by default).

$ hugo server -D
Start building sites …

                   | EN
-------------------+-----
  Pages            | 84
  Paginator pages  |  2
  Non-page files   | 71
  Static files     | 95
  Processed images |  0
  Aliases          |  1
  Sitemaps         |  1
  Cleaned          |  0

Built in 91 ms
Watching for changes in /home/user/dev/techtalk/site/{archetypes,content,data,layouts,static,themes}
Watching for config changes in /home/user/dev/techtalk/site/config.toml
Environment: "development"
Serving pages from memory
Running in Fast Render Mode. For full rebuilds on change: hugo server --disableFastRender
Web Server is available at http://localhost:1313/ (bind address 127.0.0.1)
Press Ctrl+C to stop

By default, the local server will be available at http://localhost:1313/.

Theme customization

Themes are quite easy to install, as they can be added as a git submodule in the themes folder. We choose to use and customize the Hamburg theme . We added our custom fonts and css in the static folder. Customizing a theme is quite easy with Hugo. The page templates are html files, and we overrode them with our own files by placing them in a folder higher in the lookup order . We chose to use the layout folder at the root of site folder.

Post migration

To migrate our old posts into Hugo, we simply fetched the html content from the WordPress posts and created one folder or markdown file for each post. For posts containing images, we created a folder inside the content/posts folder, with the title of the post, containing the images and an index.md file. For posts without images, we just created a markdown file post-title.md inside the content/posts folder.

By controlling the naming of posts, we managed to expose the same URLs as in the previous blog. This way, we were able to link the disqus comments section associated to the WordPress posts to the new posts on Hugo. This also ensure that all our previous social medias content (tweets, Facebook posts, etc.) will still be accurate, and without dead links.

Production site

After migrating all the posts, all we had to do was launch the build of the site :

$ hugo
Start building sites …

                   | EN
-------------------+-----
  Pages            | 77
  Paginator pages  |  2
  Non-page files   | 71
  Static files     | 95
  Processed images |  0
  Aliases          |  1
  Sitemaps         |  1
  Cleaned          |  0

Total in 103 ms

The output of the command is a static site, by default available inside the public folder. We simply had to synchronize the content of this folder on a machine with a configured web server, and voilà ! The blog was resurrected !

We are very satisfied by this switch to Hugo and the static approach. It fits our usual development workflow: the posts can now be reviewed before going live using Gerrit, our code review tool, which allows adding review comments and incremental posts versions, which was not possible on WordPress. A static site is also much easier and lighter to host. And it should protect us from sneaky inflatable bounce houses advertisemnt links ! ;)