WordPress publishing tool

Why I dropped static-site generators in favor of WordPress

Moving my blog away from the Python-based static site-generator Nikola and over to the PHP behemoth WordPress wasn’t an easy decision. The decision ultimately came down to choosing which of these two things were the most important:

  • Nikola makes programmer-perfectionist-Daniel happy.
  • WordPress makes enjoys-writing-articles-Daniel happy.

I barely know how WordPress works and that is fine. Programmer-me isn’t happy about not being in control, and I’m most definitely not happy with having to install plugins to remove unwanted core-functionality rather than installing plug-ins when I want to add more functionality. Nikola had a bare-bones and understandable core which I supplemented with plug-ins to fill in the edge use-cases. WordPress has this turned on its head and includes much functionality with its core distribution that I find undesirable and need to disable.

What drew me to Nikola in the first place was how easy it was to read and work with their code. I really appreciated understanding and [for the most parts] being able to tweak the platform to fit my needs. WordPress core is far more complex and much harder to understand. I feel like I’ve lost the sense of control over the software I use and in many places I work around it rather than with it.

On the other hand, I was able to achieve everything I wanted to do in WordPress and convert my heavily customized theme and installation for Nikola to WordPress in just 30 hours. I also appreciate not having to manually resize and rework images assets in a bunch of different sizes for responsive images every week. This was all manual labour with Nikola but WordPress does it all for me.

A big benefit with WordPress is the much richer selection of plug-ins. The plug-in community doesn’t seem to cooperate on anything because the facilities provided by WordPress.org kind of hinder rather than foster collaboration. There are many forks of plug-ins that provide the same basic functionality, and I believe these forks mostly originate around the ecosystem’s lack of good collaboration tools. It’s often hard to find the right plug-in when there are so many plug-ins that do nearly the exact same thing. Despite that there are many capable plug-ins around and I found plug-ins to fit most of my needs. I had to write my own caching header plug-in and will have to reimplement my Windows Live Tiles plug-in for Nikola for WordPress at a later time.

Using WordPress I can now properly schedule posts and fully expect them to be published when I expect them to, have social media posts sent out automatically on time, and do dynamic content on the fly. This makes it much more fun to write as I can finish articles, schedule them for later, and have fresh content appear automatically on the site every week. The benefit of scheduling is that I can focus on the joy of writing and exploring technology rather than having looming self-imposed deadlines. I experimented with various workflows for working with scheduling of dozens of articles in a static site-generator. In short, this requires a lot of work and every scheme I came up with fell apart pretty fast.

I can now also use the WordPress apps on my iPad and Android to write blog posts without going through clunky mobile terminal shells. I’m happy with this increased mobility, as with Nikola I relied on having access to my computer to correct a spelling mistakes or jot down a quick draft. Being able to quickly fix mistakes or broken links really makes my inner perfectionist happy. Having to rebuild and redeploy the whole site while being tied to my computer

Even though the HTML output on my site is mostly the same as before, I’ve notice a 11 % increase in traffic from Google since moving to WordPress. I’m not sure why that is exactly, but it could be due to the site’s new commenting feature or possibly because of the new “Related articles” list below each article. Previously, “Recent articles” were loaded in with client-side scripting but now each page contains contextually related posts. When correcting for the increased traffic, these related links are still clicked 28 % more than the previous recent articles links were. It’s possible to recreate this feature in a static system, but it’s frankly hard to do and it would require rebuilding every page every time an article was changed or a new article added. Something which is frowned upon in the static-content management world.

I’ve enabled comments and pingbacks on every article. A static-site generator can’t have a dynamic comment system without relying on a third-party service like Disqus and relaying on client-side scripting. I’d rather be in control of things myself even though this means dealing with spam comments. (All comments are moderated, so you readers should never be bothered by them.) The new comment field is a bit empty, so why don’t you go ahead and leave a comment now?

Update : I’ve disabled comments again. Maybe it’s time to reconsider a static generator?

In summary, I’ve replaced a publishing platform I was happy with and felt I had a bit of control over for a better and more flexible tool for writing and promoting my content. I’m still going to use Nikola for different projects that change less often than a blog.