In this series I will talk about the technical implementation of this website and how I automated the most annoying things.

Status quo

When I first created this website I chose Wordpress as my content management system for several reasons:

  • It’s widely used and there are plenty of resources available (themes, plugins, …).
  • You can self-host.
  • Easy integration of contact forms and other interactive elements.

So, I set up Wordpress on my vServer with Docker and Traefik. It took a while to set up everything correctly but than it just worked like a charm. Unfortunately, it didn’t feel right. Changing the content of my website was a weird combination of creating a post or page in Wordpess and changing the theme directly. Maybe there is reasoning behind it which makes sense to some. For me it felt unnatural.

Besides that, I wasn’t sure how to backup my website in an easy way. So, after two month of running Wordpress, I decided to move on and build everything with a static website.

Static website

A static website is a set of HTML and CSS files. Back in the day, people hand-wrote HTML files and styled their website with CSS. That’s what I did 20 years ago and I am never going to do that again. It’s too much pain and too little focus of what matters to me: the content of my website.

Nowadays, there are static site generators. The most popular one is Jekyll, but there are many others such as Hugo, 11ty, Gatsby, and many more. The biggest advantage of Jekyll is its large ecosystem with thousands of themes and plugins. However, I couldn’t get Jekyll to work locally so I looked for another static site generator that fit my needs and ended up using Hugo.

It also solved my backup problem. I work on the site locally, push to GitHub and from there deploy to my webserver. So, the content and configs should be in at least three locations at all times. he details of that will be the content of the second part of this series.

My choice: Hugo

Why did I end up choosing Hugo? The reason is pretty embarrassing: There is a Arch Linux package for it which saves a lot of trouble when trying it.

Some other things that are great about Hugo:

  • Good documentation with everything that you need.
  • Enough themes to find one that fits any use case.
  • Efficiency

For my use case I could have gone with any of the site generators but Hugo felt right, so I decided to go with that.

Getting started it quite easy:

hugo new site <name of website>
cd <name of website>
git init
git submodule add https://github.com/<theme>
echo "theme = '<name of theme>'" >> hugo.toml
hugo server

That’s all that is to it.

Creating content

Creating content for the website is quite easy. All you do is writing Markdown and Hugo creates the HTML files. The looks come from the template. The content comes from you.

All your pages go into the content directory. Each subdirectory is a subpage at the end of the day.

Testing locally

Technically, all there is to testing locally is to run hugo serve in the top level directory of your project. This will server the website at localhost:1313 for you to check. It automatically reloads the website every time you change a file which is amazing. I wouldn’t want to miss that.

Summary and what’s next

In short, I got rid of my Wordpress instance and replaced it by a static website generated by Hugo.

In the next part of this series I will talk about the details of the deployment of this website. As a teaser, there will be a bit of yaml to configure Docker and GitHub Actions.

I am open to do contracting as a backend software and data engineer. I like to automate processes. I like technical writing. Check out how we can work together.