JeffGeerling.com has been Migrated to Hugo

Since 2009, this website has run on Drupal. Starting with Drupal 6, and progressing through major site upgrades and migrations to 7, 8, 9, and 10, I used the site as a way to dogfood the same CMS (Content Management System) I used in my day job for over a decade.

But as time progressed—especially after completing a grueling upgrade from Drupal 7 to 8—my enthusiasm for maintaining what's now a more enterprise-focused Digital Experience Platform or 'DXP' for a personal blog has waned.

Not to mention, the blog is a passion project. I use it as a scratchpad for thoughts, and deeper dives for my YouTube videos. Time spent maintaining a complex CMS is time I can't spend actually writing (not to mention time spent on everything else!).

Why Hugo?

I've long-since moved my other hobby sites to static hosting. For older sites I don't actively update, I scrape and mothball them. But for sites I wanted to keep active, I converted them to Jekyll or Hugo, both of which are competent and full-featured modern SSGs (Static Site Generators).

Jekyll is perfect for the static sites I host for free on GitHub Pages, like the Raspberry Pi PCIe Database or Project MINI RACK, but I'm not a Ruby programmer, so I like Hugo for anything I run on my own infrastructure. It's simpler to set up and a little faster.

Housekeeping

Anyway, I've been working on the migration in this GitHub issue, and there are bound to be mistakes, broken image references, and probably some old URLs that just go poof!

I try to keep everything where it is, or add redirects. But with 20 years of baggage and 3500+ posts (many of those were individual photos converted into 'blog' nodes in a prior upgrade... oops!), it's hard to run a perfect migration.

Markdown Workflow

I've been writing all my posts in Markdown since 2020, and even before that, was drafting them in Markdown in Sublime Text, then exporting that to HTML via MarkdownPreview.

So having a tool (Hugo) that uses Markdown natively is a breath of fresh air.

Beyond that, I've grown fond of 'sticking to the defaults' over the years. On my initial Drupal 6 site, I installed something like 30 modules (plugins in Drupal parlance), but almost all of those modules bit me in one way or another as I upgraded to Drupal 7, 8, 9, or 10...

Honestly, upgrading from 8 to 9 to 10 was easier than 6 to 7 and 7 to 8, simply because I had stripped my site down to the basics.

However, in so doing, I also made my content authoring experience a bit horrid:

1. Write a blog post on my computer in a Markdown file
2. Create new unpublished Drupal blog post
3. Paste the Markdown content into the body and add a title
4. Individually upload each picture
5. Put cursor where each picture goes in the content, scroll down to the uploaded picture, click 'Insert' to insert the preformatted <img> markup, and rinse-and-repeat for all images (sometimes up to 25-30 per post!).
6. Clear out the 'Authored on' field to make sure the date would update when I publish the post
7. Toggle the 'Published' option and save the node
8. Run an Ansible playbook to drop Drupal caches, Nginx caches, and trigger a Cloudflare purge of the relevant URLs (ongoing DDoSes since 2022 caused me to really lock down my caching)...

It was a lot. Just to publish a blog post—and none of that helped with writing or being creative, it was just a bunch of work.

Yes, I could automate each step in Drupal. There are even modules for Drupal, like Scheduler for scheduling posts and updating publish dates, and Cloudflare for purging CDN cache... but you know what? I used to use those modules, but after four Drupal upgrade cycles, I was burned out on managing patches for months, years, or indefinitely since some of the modules took that long to have a stable release for [current Drupal version].

And don't get me started on having to rebuild entire content authoring workflows (e.g. WYSIWYG editors, media management, and content fields) every time a major Drupal version was released! That specific type of churn, thankfully, is not as bad these days, but it was really bad prior to Drupal 10 or so.

For Hugo, since my workflow already started with a Markdown file... the whole process is done after step 1, basically.

To publish, I guess I do have to update the date in my post's frontmatter, and change draft to false, but that's about it. hugo && git commit -m "Updated post." && git push and the blog is up to date!

And for maintenance, don't get me started on managing Composer, Drush, PHP, MariaDB, Nginx, Cloudflare, etc. — for an enterprise website, with multiple content workflows, dozens or hundreds of users with RBAC, etc., sure, it's fine. But for a blog where I just want to write and publish, it has been wearing me down for the past few years.

TODOs

Comments will be missing site-wide initially, as I've chosen to tackle a self-hosted static site commenting system in a 'phase two'. I love having comments enabled, despite the moderation overhead, and don't think blogging is the same without them.

I also loved having integrated site search, since I use my blog as a project journal, referencing it often. The Drupal site was integrated into an Apache Solr search instance I also ran as part of Hosted Apache Solr... which I sunset years ago at this point. So I'll have to decide how I want to implement search within Hugo.