4 minute read

It's alive!

I finally did it. I migrated my aging website to the latest and greatest static web framework. And it only took me just shy of a decade. My old website used the Victor Hugo static site generator, leveraging Gulp and Webpack for the asset pipeline with Netlify as the Content Management System (CMS). These were cutting edge when I migrated from the first iteration of my website in 2016, which was written in PHP and hosted on GoDaddy.

This latest iteration of my blog uses Jekyll with GitHub Pages. The admin front-end isn’t as nice as Netlify’s was, but I also don’t need to worry about any surprise charges if one of my posts goes viral (highly unlikely, but not impossible). I think this latest arrangement strikes a pretty nice balance between the hand-holding of Netlify versus the go-it-alone approach of writing PHP from scratch and hosting it on a GoDaddy instance.

What was the impetus for this change, you might ask? Well, one of my former coworkers and good friends mentioned their surprise to see that I had a blog from a commit notification on GitHub. They asked that I add an RSS feed feature so that they could be notified when I posted a new entry. Well, that presented a problem as my version of Hugo doesn’t support RSS feeds and the upgrade path of going from (no joke) Hugo 0.0.3 to Hugo 0.144.2 promised to be fraught with suffering. Not to mention that Netlify, the service that I depended on to build and deploy my Hugo site whenever I pushed to git, had subtly been raising their prices over the years.

After some research I found that GitHub Pages was the most popular solution after Medium, Wordpress, and Squarespace. Not that I have anything against those two services, but Netlify had left me gun-shy with regards to paid hosting arrangements. So GitHub Pages it was. With the back-end hosting determined, all that was left was determining front-end generator. The GitHub documentation pretty explicitly nudges you towards Jekyll if you want something beyond the primitive front-end that Pages gives you, so I went with that. Next, Jekyll itself supports custom theming. After a brief study of the 1,897 public theme repositories I decided on minimal-mistakes. Not only because it was the single most popular theme with 13k stars as of the time of publishing (ensuring the best support and documentation), but also because it offered a variety of color schemes for even greater customization.

Puttin on the Ritz, er, theme

With the platform front and backend set, all that was left was to migrate. Because Hugo and Netlify use markdown for the blog format, it was pretty straightforward. Just drag and drop the .md files from my old blog to my new blog. There was just one catch. Hugo used an ISO 8601 date within the markdown file to determine what to show as the published date, whereas Jekyll uses an ISO 8601 date from the name of the file itself to determine the published date. Rather than go through 123 separate files and manually copy the dates in order to rename the files, I decided to let our AI overlords have a crack at it first. GitHub Copilot is now supported in the terminal. You can use it to request shell command suggestions. So I gave Copilot the prompt “Take the date field inside each file and use it to prefix all the file names that do not already have that prefix as part of their file name. The format should be YYYY-MM-DD-“. Copilot responded with:

for file in *; do 
    date=$(jq -r '.date' "$file"); 
    prefix=$(echo $date | cut -d'T' -f1 | sed 's/-//g'); 
    if [[ ! $file =~ ^$prefix- ]]; then 
        mv "$file" "$prefix-$file"; 
    fi; 
done

and helpfully offered to copy it to my clipboard so that I could paste and execute it (Copilot wisely is prevented from executing commands on its own!). This command didn’t completely solve my problem, but it did get me 90% of the way there.

Migrating my blog entries was only part of the equation however. I also needed to migrate my domain, jjmtaylor.com, to resolve to my new GitHub Pages Address (A) and Canonical Name (CNAME) records, rather than my old Netlify records. This was a little more involved than I would have liked because in 2023 the domains maintained by Google Domains (who I had originally purchased the rights to jjmtaylor.com through in 2016) were sold to Squarespace. I don’t know if you’ve ever used Squarespace, but their features, prices, and record update propogation left a lot to be desired. So after another brief stint of research I found Cloudflare to be one of the most highly recommended domain registrars out there. I purchased jamesjmtaylor.com and tested the domain propogation. I found that its A and CNAME record changes for my GitHub Pages website propogated within minutes, whereas Squarespace still had not resolved to the new blog page after days of waiting. So I initiated the transfer of my jjmtaylor.com domain to Cloudflare and for the time being, re-linked my blog to jamesjmtaylor.com. The irony that jamesjmtaylor.com had been my original domain name through GoDaddy before they decided to squat on the domain and demand $120 per year (as opposed to the initial $6 entry fee) was not lost on me. Apparently even GoDaddy can’t sit on a domain indefinitely.

And that sums up my website migration odyssey. I hope you were able to pick up some tips and can avoid some of my pitfalls as a result of reading this longer-than-average (for me) post. Until next month!

Updated: