It’s been an…adventure.

Why Switch from Publii to Hugo?

I am switching from Publii to Hugo because I wanted to take advantage of the text notes I was already taking with Vimwiki for my various projects. The Publii interface was nice, but I’m already writing notes in a format that doesn’t require me to use their WYSIWYG editor. I know that seems lazy, but it’s an extra step that caused just enough friction that I wouldn’t update the blog.

I picked Hugo because it seemed simple, used text files vs. databases, etc., and honestly, I found a sick Gruvbox based theme that I liked. Gruvbox is the one true color palette.

Working through the kinks

Setting it up was actually really easy. I got it all working locally in about an hour, but when I went to deploy it to the S3 bucket, it just didn’t work. I discovered that AWS S3 buckets don’t like “pretty URLs”. In other words, S3 buckets need the URL with the “.html” at the end, or it throws an error.

The fix is using “ugly URLs”. This argument, added to the Hugo config.toml, should add the .html to the end of all of the URLs. It does that, but it also provides the ENTIRE URL. So, if you clicked the link to the ‘blog’, instead of going to wesgould.com/blog.html, it would go to wesgould.com/www.wesgould.com/blog.html. So either Hugo has a bug in it, or the way my particular theme is set up, that ALSO didn’t work. After fighting it for entirely too long, I decided that I didn’t want to recode the entire theme. I’d just move from AWS to GitHub pages–which does support prettyURLs.

It seemed simple and would save me $0.50 a month (since getting TLS certs requires CloudFront, which costs the exorbitant $0.50/mo). It also aligned with the Git workflow I was already using.

I read a couple of tutorials but ultimately ended up following this amazing YouTube video. It walks you through creating a “working code” repository and a public repository where you can publish your static site content.

Hooray! This will be easy peasy!

But, I ran into another problem and beat my head against the wall. The site deployed and seemed to work fine, except for the Blog URL. It was directing me to a weird readme. The source of the page referenced Jekyll and SEO optimizations. I grepped for those strings in my code and couldn’t find them. Long story short, the culprit was a “gh-pages” branch of code in my website repo. Having a gh-pages branch (designed for Jekyll) in your repo tells GitHub to kick off an automated workflow to deploy a static site. Cool.

I’d started to follow this tutorial before I found that YouTube video. So, I had created a gh-pages branch and totally forgot about it. Apparently, that magical branch automatically injects stuff into your code/site as it’s updated—and in my case, broke the “blog” links. Deleting that branch fixed all of the problems.

It’s working now, and I am looking forward to tuning it. The only thing I don’t like is that it, probably correctly, follows the system setting for light vs. dark mode, even though I’ve set the default to dark. Light mode Gruvbox is gross. I might try to fix it and submit a PR to the theme editor. I’ve seen other themes that let users choose the system, light, or dark.

The last thing I need to do is clean up DNS so my actual domain displays this instead of my broken S3 version.