New CMS (II)
Posted on
tl;dr – this is Hugo published on Netlify.
From Anchor
Couple years down the road, it's time for a new CMS! I last wrote about moving from Anchor to Bolt in 2015.
The motivation? I have to go around patching things at work, I really do not want to spend my weekend patching my own services as far as possible, especially when it's not as simple as bumping the version on a Docker image spec and seeing what breaks. (Just kidding! You bump it very carefully and in staging first!)
My previous Bolt CMS was hosted on a cPanel server on a webhost that I don't even want to link to – I still have an account with them only because they screwed up billing once and I ended up paying the PayPal invoice, and accidentally renewed for four more years instead of two.
There's no shell access on these servers, so no git pull, you have to carefully upload individual files over SFTP... it's not fun at all.
The original plan with Bolt was to figure out if I could use it for a side project. I wanted to replace a rather dodgy old WordPress site with a whole bunch of outdated plugins, with something on a fresh PHP base (for cPanel hosting compatibility) and a serviceable web UI.
Bolt is pretty interesting, a fair bit of the config is in YAML files, a pretty divisive topic, but as someone who's ok with YAML it feels more convenient to have the docs open and edit the file, than clicking around WordPress menus.
The flexible ContentTypes and Taxonomies support looked like a great fit, but there was some unexpected behaviour around the file uploads/attachments that didn't quite work out.
To Bolt
That side project has since been firmly abandoned, and I don't like fiddling with trying to update Bolt CMS over SFTP, so here we are on Hugo! It seems like the fresh, new thing nowadays, and doesn't seem too esoteric.
On first glance, Hugo looks pretty sane. The docs are not fantastic but they kinda work. It's nice that some themes have been ported from Jekyll and elsewhere. There's also a relatively new Hugo Pipes feature which is an asset pipeline, which I haven't really had to use yet.
The whole "this is written in Go and it's blazing fast" thing is a little off-putting but that seems to be a general Go community thing.
As far as a static site generator goes, it seems good enough for simple sites, though if you're coming from some other CMS, you should carefully check out the docs to see if all the features you need are indeed implemented.
Netlify
Now, as for deployment – I think a lot of people use Jekyll because that's what GitHub Pages works with. You can host a Hugo-generated site on GitHub Pages too, but it's a little awkward because it seems like you have to commit the generated content to your gh-pages branch.
That's where Netlify comes in, they have some infrastructure that provides a build environment for Hugo (or your favourite Ruby/Node/Python-based static site generator) to run on your Git repo, and then take the output and publish it to their static content CDN.
I have no idea how and why they can offer a free tier for anyone to use, but they seem to be trying to push their own "JAMstack" concept. Basically they want people to make websites that are primarily pre-built static content, with client-side Javascript code that interact with backend APIs if necessary. Naturally, that makes sense for the "static content build environment + static content CDN + authentication + form data collection + FaaS" niche that they're building.
Netlify still has some rough edges, such as needing to email support to regenerate your Let's Encrypt TLS certificate if you add more custom domains to your account after the initial TLS certificate generation, but can't really complain when it's free.
One large user of Netlify seems to be the kubernetes/website repo, who use it to build and deploy site previews for pull requests, and recently you can see GovTech's isomerpages GitHub repos using Netlify to render their staging sites, though it seems like they might be using Amazon CloudFront to serve the production sites instead.
Edit: it's a little meta but you might be able to see the PR builds in action on the PR for this post – while it's building the build status is yellow and links to the build progress page on Netlify, but if it's complete successfully the build status turns to green and it links directly to the deployed preview site.