In the fall of 2005, I installed WordPress on the free hosting space provided by my ISP in France (fittingly called Free). I had very little experience with PHP but enough so to get the site up and running.

Initially called Lost in translation (after the eponymous movie starring Bill Murray and Scarlett Johansson) and I was writing about… well, I frankly don’t remember. However it must have been such poor writing that I decided to wipe all of it in the beginning of 2008 (even the wayback machine didn’t care to keep a trace of the content, to give you an idea of how bad it must have been). The subsequent writing wasn’t much better but I apparently wasn’t ashamed enough about it to wipe it out again.

The site has changed quite a bit over the years and has evolved from being a simple blog to being a proper site with a list of talks and a now page.

The only constant during all that time has been the underlying technical foundation, WordPress. Let’s talk about WordPress for a bit, shall we?

WordPress

WordPress has served me well for a long time. The following is an attempt at conveying what worked well for me, what didn’t work well for me and what eventually led me to switching away from WordPress.

The good

Installation and hosting

I find WordPress to be quite easy to set up. In the early days, I remember that this wasn’t straightforward and that I had to wrestle with an .htaccess file and file permissions to get to where I want (especially on hosting environments where I didn’t have full control of things). Over the years I have hosted this site on various PHP hosting provides, at Clever Cloud and finally for the last years it was hosted on a tiny Hetzner Cloud instance).

Availability of standard themes

There are many free WordPress themes out there, including the ones that come out of the box with it. I switched themes quite a bit over time and ended up using the X Theme for quite some time. Whilst this is a paying theme, it had most of what I wanted out of it - but not all of it. More on that later.

Extensibility through plugins

“There’s a plugin for that” probably describes pretty well how to get WordPress to do about anything. There’s many plugins out there and whilst many of them aren’t up-to-par in terms of quality, it is easy enough to find something that works in most cases. This allows to customize the CMS in many ways without having to resort to coding.

The bad

Plugin bloat

Whilst plugins allow for easy extensibility, it makes it very easy to install too many plugins which end up bloating up the site and cause unexpected behavior. What doesn’t help with this is that there are just so many plugins for the same purpose, all with their strengths and weaknesses (and I’m not talking about free vs. paid plugins here - just about the amount of choice in general). Over the years, WordPress has steadily included some of the commonly used functionality in its core, which I think is a good thing to some extent - but keeping track of what could be covered by WordPress itself or what is best practice requires another type of dedication to the platform than the one I had as a casual webmaster.

Performance

WordPress performance out-of-the-box isn’t too bad, but add a feature-full theme (such as the X Theme I was using) and a bunch of plugins and things look quite differently. I have spent so much time trying to improve the PageSpeed Index of the site that I don’t want to talk about it any more. I also ended up getting - you guessed it - a paid plugin to get the site faster. But I never truly got any satisfying (at least, to me) score with the platform.

I also ended up hiring a WordPress designer to create a custom theme for the site (and another one to update it / improve it somewhat) in order to get a lightweight version of what I had puzzled together. This helped to some extent, with the caveat that it made it more difficult for me to update the site. In the end I had to really dig in and work on things on my own to get what I wanted over time.

The ugly

Fear of update

WordPress releases new versions quite often and minor updates are getting installed automatically. Additionally to this, plugins also have new versions (and you can choose to have them updated automatically). If you host WordPress on your own machine, OS updates (mainly security updates and also PHP version updates etc.) are also a thing.

All of this has led to the site breaking quite often after an update, for various reasons (incompatibility of a theme with the new WordPress version, bugs in new plugin versions, obscure backwards-incompatibility issues with regards to PHP, you name it). This phenomenon is of course not a particularity of WordPress itself, it happens with any suffisciently complex piece of software. The point is however that the many moving parts are core to how the WordPress CMS and ecosystem are built, which in my experience increases this type of issue

Maintainability over time

17 years with WordPress is a long time and so over the years I ended up writing content through the WordPress editor, as markdown using some type of markdown plugin and then again through the new and improved WordPress editor (which by now is very nice, I must say). All of this has led to the various articles to be built using inconsistent expectations as to what plugins were installed (e.g. for syntax highlighting). I often noticed months later that a particular change had completely botched older articles, or that images had just disappeared for one reason or another.

Over time, the amount of work I needed to do to get the status quo of the site running while still changing things a bit here and there got out of hand so I ended up looking for another solution.

At this point I should say that sticking with WordPress for so long was also in part due to my falling pray to the sunk cost fallacy.

Hugo

Hugo is a static site generator. I played with it last year for the thoughts.bernhardt.io site (which I now merged into this one) and it is quite easy to get started with.

At this point I’m just starting my journey with Hugo and I don’t really have enough experience to provide a good / bad / ugly type of comparison. So I’m just going to write about the good parts for now.

It’s so fast

Written in Go, Hugo is extremely fast. It generates a site in a very short time and the PageSpeed index of a generated site is much, much better than anything I’ve ever achieved with WordPress. Hooray!

Easy to customize

Hugo uses HTML templates with a custom syntax. After a bit of reading and trying things out it is quite easy to build custom templates to show things the way you want them to show. For example, the testimonials are built this way.

Themes

There are many Hugo themes out there. When I first tried out Hugo themes I found many of them to be broken / not working with the current Hugo version. The Even theme that I am using now hasn’t been updated in a while but still works, and I hope this will be the case if I update the Hugo version.

Deployment

I’m using Netlify to deploy Hugo automatically. This was very easy to set up. There’s a GitHub hook that automatically deploys the site when I push a change to the Git repository.

How hard / long was it to do the switch to Hugo?

I’d estimate the effort to be about a about 1,5 weeks worth of work.

I used the WordPress to Hugo exporter plugin for WordPress which generated okay-ish markdown and also a lot of broken markdown. The broken markdown was a result of my usage of various editors and syntax highlighting plugins over the year. I probably spent about 3 days just going over each and every article and fixing them by hand - heavily using regular expressions in the process.

Alas, some of the broken things were so broken that even regular expressions didn’t help.

Creating custom templates for some of the content was also very easy, as well as getting the multilingual part of the site to work.

I spent a bit of time getting the layout to look like I wanted it to and to be responsive, but that was quite easy in the end.

I use Commento.io for the comments migrated from WordPress which works very nicely. By the way, apologies to the people who wrote comments after I exported the comments from WordPress, your comments are lost in the void. The export / import process was a bit involved (I think in part because something was just off with the data that came out of my 17-year old WordPress comment trail) so I only did it once. The Commento support was very helpful with this.

Conclusion

For the moment I am quite happy with the decision of moving to Hugo. Let’s see what I have to say about this in 17 years :-)