Moving from Hugo to Wordpress
This post is one I wrote a while back but never published, as I’ve found some free time now, I’m going through and putting together posts that I jotted down but never got to publishing.
Picking a static site generator
The blog you’re looking at right now (as of January 2017) is a staticly generated site generated with Hugo. There are lots of options in the static generator races: harp, jekyll, rocksmith, and I looked at some of them but having recently dealth with [Golang]() and really enjoyed it’s conventions, simplicity, speed, and ease of install/packaging (though the to-vendor-or-not-to-vendor thing was rocky at first), I reallly wanted to give Hugo a shot.
One of the great things about statically generating sites is that the tool is actually not super important – I’m super sure you could pick any one of the tools I mentioned above and be happy. I like the attention that just about all tools pay to the content - most tools work to fit in different content types and do their best to get out of your way. Previously this site was run on Wordpress, and while Wordpress is fantastic for users that may not be very technical, it feels a bit heavy for JUST a blog, when one is familiar with how simple HTML/CSS/JS are. Also, static generated sites should (in theory at least) be much less vulnerable than a wordpress installation (even with the fact that wordpress is constantly patching vulnerabilities and has become quite secure).
Long story short, use SchumacherFM/wordpress-to-hugo-exporter. Since Wordpress has a pretty good API, and facilities for exporting data, I thought maybe I should write some sort of short script to parse the XML generated by wordpress and write posts that match what Hugo expects, and then 3 seconds of google searching brought me to the previously mentioned exporter. Everything was super easy.
Also, check out awesome Hugo themes here!
Running the blog with Docker for isolation
It’s extremely easy to create a docker file that uses the official NGINX image, and does nothing but pull in (Dockerfile command would be
COPY) the generated files (a simple
Makefile wraps this all together for me), and place them in
/var/www of the container (which is the default place it serves from).
Why even bother pulling in Docker when it’s just static files? Well I prefer to have most of my services really just be reverse proxied from NGINX, because it prevents me from having to worry about excessive NGINX configuration (of course, it wouldn’t be excessive for just serving a folder), and because I can do a quick
docker ps and see how things are running.
I also feel that docker provides an improved local development experience (knowing that exactly what I see locally is exaclty what will be shown in production), and makes my deployment easy (I actually pass the docker container over to the remote server and
docker run it).
It also maybe completely the case that Docker is overkill for this use case.
Hooking up the container to run with systemd for ezpz management
If you haven’t, check out my post on how to wire up docker containers with systemd.
Of course, after you make the appropriate unit file, make sure to start & enable it so that when you (or something else) forces the server to restart, your blog comes back up.
Don’t forget SSL!
Even for a static site, it isn’t hard to add SSL to your reverse proxy (NGINX for me). Check out Let’s Encrypt, downloat
certbot, and get yourself some free SSL. Certbot will even do things automagically for you if you ask nicely.