Welp, I've done it again. I decided to go back to static instead of using WordPress. I want to explain why I made that choice and go over what I'm doing now.
Earlier this year, I decided to move from managed hosting to a Linode VPS. I've been doing more app programming in Python and my shared hosting plan - while great - didn't let me use runtimes other than PHP. There are a couple projects I wanted to make publicly available, so moving to a new host was pretty much the option I was left with.
Instead of paying for two hosts, I've also cut down on the number of things I'm running, focusing instead of the important things. The Linode plan I can afford is very low powered and after experimenting for a little bit, WordPress is a little too heavy for my modest storage, RAM, and bandwidth limits.
Several years ago, I wrote about using a static site generator and then about how I was moving back to WordPress. At the risk of losing the game by switching again, well...I'm switching again.
Last time didn't work well because I didn't have a good process for writing and deploying the site. This time around, I've gotten some great help from people I've found on Mastodon to get a workflow that works well for me. For example, last time required maintaining a full repository of writing on Github. Jekyll is also built in Ruby, which I don't know. It was difficult to know where things were in the publishing process and in the end, it was all hosted by Github, not me.
This time, I've decided to use Pelican, a static site generator written in Python. It was important to me to have a better idea of everything from the post creation to how to create my own template. It's quite simple - I write posts in Markdown and Pelican spits out a directory of HTML. No magic code repository required and no wondering where the HTML actually is.
Pushing to the server
In learning about how to manage a new workflow, I kept seeing reference to rsync. I didn't know what it was and hooo boy, now that I know, my life has changed. This is one of those truly magical pieces of software that you wish you'd known about years and years ago.
In short, I can do everything - all my writing, templating, and publishing - on my computer without having to push anything up to the server. I can see the generated site to make sure all is well before pushing. Once it's done, rsync can take the created files and push them to the server efficiently and quickly. Since it's all HTML, there isn't anything different here than on the server, so the result is a carbon-copy.
All this to say is that my site feels more resilient to change than it did with WordPress. When I migrated the WordPress version of my blog, I had to copy source files, copy directories, get a database dump, and then reset the nginx server to handle incoming requets to WordPress. With this, I can copy and paste the entire
output directory here - or anywhere - and it'll Just Work.
Will this be my last blog switch? Who knows. I'm happy with this because it's easy to write and manage and requires next to no resources on the server, which means I have more space and resources to play with the fun stuff.
One side effect of static is that commenting isn't embedded anymore. I have copies of all the old comments from WordPress and I'm going to slowly move those back into the posts as text. If you have something you want to contribute or push back on, you can send an email any time to email@example.com and I'm happy to pick up a conversation.
Many thanks to AlexMillerDB and Benjamin Hollon for helping to find some hidden wonk in the redesign. Some things are incremental fixes (link syntax, in particular) and a couple others were to improve usability, especially on mobile.