Trying Out Hugo

Trying out Hugo for the blog

Well I have had my eye on Hugo, a static site generator for some time now. It is written in Go, supports markdown, has a rich theme system, and as it says it generates html you can just drop in for nginx or whatever your webserver happens to be.

I’ve been using hexo for some time now, and it has worked quite well, but I’m not fond of managing the Node dependencies, and I don’t know Javascript all too well so I wanted something that was both open source and written in a language I knew and could more easily contribute to. and on top of that, Hugo is blazingly fast.

Migrating off Hexo to Hugo

I’ve started to get a grip on how things work in Hugo, the documentation isn’t the easiest to grok, but thankfully it has a thriving community, so it is pretty easy to sort out what you need to do when converting.

I was pleasantly surprised by how easy it was to migrate from Hexo. There wasn’t a conversion tool like there are for some other platforms, but since Hexo is a Markdown generated site as well, you really only need to update shortcodes. With my site I had really only used a few for Youtube videos, and Hexo had one for images that I used instead of Markdown. With that in mind it was pretty easy to just write a regex to find one short code and convert it to either Markdown or the new shortcode. The only catch with the images was the alt-text. I put a placeholder in and adjusted it where I felt like it.

The regex I used in VSCode:

^\{\% asset_img (.*) \%\}$
![alt-text](/static/dir/path/$1)

I only had a handful of posts I needed to update so I just went through them in VSCode which the find/replace allows you to use a regex and supports capture groups, obviously replace the /static/dir/path/ with the actual path to the image.

I don’t have a strong opinion on static site generators, but I like Hugo so far. I had considered moving to it some time back but got the impression using it as a blog would be less than ideal, not sure what gave me said idea as it works great!

Publishing content

I was never a fan of how Hexo went about publishing. There is no reason I couldn’t have just generated the content and pushed it on my own, but for whatever reason I tried to stay in the ecosystem. Hugo, comes with no opinion on how to publish. Since I host my own webserver for stuff like this I simply generate the content, and use rsync to push the data to the right place.

rm -rf public/ && hugo && rsync -avz --delete public/* blog.heschlie.com:/path/to/blog/

Once I am ready to publish I run that (from a makefile cause why not) via make publish and thanks to the beauty of ssh, I’m not even prompted for a password, quick and simple, and keeps the generated files out of the git repo, and no messing around with deployment options in the config.

RSS feeds

This one took me a minute to sort out, it turns out it was already generating the RSS xml files, they just weren’t where I thought it would be. I’m used to the site having an atom.xml or rss.xml on the root of the project. What I was actually looking for was called index.xml, but it wasn’t the one at the root directory that I needed. Hugo is a bit more clever and will generate an xml for each section, so you can watch parts of the site independently. For instance, I was looking for https://blog.heschlie.com/post/index.xml to point my automation at

Final…ish thoughts

I like it so far, only took me a couple hours to convert my posts over. I did loose my Disqus posts, but there were like…3? Apologies if yours was one of them. I could probably map the new posts over to the old ones for Disqus to find but I’m not sure it is worth it.

I really like that the Hugo is just a single binary (thanks Golang!) and has a pretty clean CLI. I always had trouble setting Hexo back up when changing to a new machine, Hugo is just grab the binary, clone the repo, start editing.

comments powered by Disqus