From WordPress to Rails

I’ve rebuilt this blog. It’s been dormant for three years — a lot has changed. I’ve been a Ruby developer for three and a half years, moving from PHP that I’ve used for over a decade. I’ve become a people manager and now help other engineers develop their craft. I will write more but the old version of the site needs some changes to help with that.

Why I opted for a rebuild

The blog used WordPress. Whilst it has its flaws, WordPress was, and in my opinion, still is, an excellent publishing platform. My time away from PHP and WordPress has made upgrades increasingly time-consuming. Recently I tried to upgrade to PHP 8 and found an error message greeting me when I tried to check the work. I had to decide if I wanted to spend time debugging and understanding this issue or migrate away to something I could maintain more easily.

Given subsequent upgrades would likely cause me similar issues I decided to spend a bit more time starting from scratch now to save time later; I could tweak how the site worked too.

Moving to Rails

My day-to-day tooling is Ruby on Rails — it makes sense to tap into that know-how. It should mean development and maintenance is relatively straightforward because I work with it daily.

Using Rails means I can use its ecosystem of gems to add functionality in a similar way I’d use WordPress plugins. I’ll describe how I’m using a few of these things.

Moving to Rails simplifies my hosting too. I managed a DigitalOcean droplet with ServerPilot; DeployHQ would deploy and build the site. All these services are great but it’s more steps than I need. Now I use Heroku and have it automatically deploy code changes once tests pass and the build succeeds. It’s fewer steps to deploy and fewer services to manage.

Going Static

Another change is to go completely static — no database behind this blog. The reason? There’s no need. I can write posts directly into views and have more control over how they are laid out. Potential security holes reduce with no logins and no privately stored information; performance has improved as no connections are needed to transfer data. No database means one less potential point of failure.

There are limitations — comments being a notable one. The previous version of the blog did allow database-backed comments; this new iteration doesn’t. For now, that’s something I can live with. If I decide to add commenting later I’ll have a lot of control over how I choose to do it, but it will take more time than updating a WordPress template file.

Design Systems

Recently I’ve been building design system components — they make building consistent UIs much quicker, help multiply effort by allowing one change to affect many places and improve reliability by being more testable. I was keen to bring them into the new blog build. ViewComponent is a gem for building components in Rails. It’s used by (and indeed came from) GitHub so I have confidence in its quality and longevity.

There are some good third-party additions to ViewComponent — as an example, Lookbook helps extends ViewComponent’s built-in previews with interactive documentation of the components.

Automated Testing

It’s possible to write tests for WordPress but it’s not as integrated or expansive as writing tests for Rails is. For clarity — I don’t believe this is a shortcoming on WordPress’ part — this is what I’d expect given their two different use cases.

Migrating to Rails has allowed me to write tests that exercise all aspects of the site, from individual components and how they’re behaving, to complete user flows. I’ve integrated test runs into my build (using GitHub Actions) to help me be sure that every deployment I make doesn’t introduce breaking changes without manually verifying everything.


I now have a more sustainable platform to write and publish on going forward. It will allow me to stay on top of maintenance and updates, present content in more ways and be confident in any changes I make.