Here I will try to describe my move from WordPress to Sphinx to Hugo and why.

Table of contents

WordPress

My first attempt at “blogging” was with WordPress. Starting was really easy, grab WordPress, place it in some www directory do some stuff with rights. On CentOS it should all belong to the apache user. Do some stuff with SELinux to make sure the automatic WordPress update works.

At first, all seems to work, creating articles is easy, and adding plugins is a piece of cake. And even the backup seems to be working.

At some time (many WordPress updates later) the backup plugin (some plugin with rsync) stopped working and I could not get to work again. This made me look at something else… Besides it is a lot of code for a simple bog site.

Sphinx

Comes Sphinx, Sphinx is a static site generator. Create the articles in rst (or some other format), generate the html, and upload them to your server. Copied the old articles and pictures from the WordPress site and pasted them into rst files.

The reason for moving away from Sphinx is that I could not tweak the pages to what I wanted. This was probably something on my side than on the side of Sphinx.

Hugo

During my research for moving away from WordPress I also came across Hugo, but at the time it did not look as a viable option, because I thought I had to know Go, but that was a misconseption from my side. After studying a book and going along with the explamples, I got to understand how Hugo works. And in my opinion Hugo is more flexible and controllable than Sphinx.

I found a great site that also uses the Hello-Friend and that is Cavelab blog, I copied some things over from his site to mine and that is basicly it.

CI/CD and gitlab

The CI/CD is only related to Sphinx and Hugo not to WordPress. The setup I use is: gitlab-ce in a docker container. The gitlab documentation describes how to enable the CI/CD capabilities of Gitlab. After adding a .gitlab-ci.yml and adding a tag to the gitlab-runner configuration I got everyting is working. There are two targets are defined: master (the main site) and develop (all other commits will deploy to the test site). After a push to either master or an other branch a gitlab job is started. After a successfull run either the main site or the test site is automaticly updated using rsync (this is part of the .gitlab-ci.yml).