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?

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.

6 thoughts on “Why I dropped static-site generators in favor of WordPress”

  1. When it comes to writing blog posts on-the-go while using static website generator, I usually write it in my mail client, sync it via Drafts folder to my big computer, and then copy-paste to terminal when at home.

    It might be possible to write posts by email, too – one just need to write a bunch of scripts for that. 🙂

    1. The waiting until I get back home bit was kind of my issue with this workflow. What if I wanted to quickly correct a typo? or add a sentence that would make my point much clearer? I don’t want to be tied to one computer to push updates.

  2. I have migrated my blog from Blogger to Octopress, then to WordPress, then to Nikola.

    While I did notice increase of pagehits after moving from Octopress to WordPress, upon closer inspection I found that lots of bots started probing for WordPress vulnerabilities, and trying to post spam comments increasing the number of visits dramatically.

    After some month of WordPressing I found that my markup was getting messier and messier every time I edit the post and my encoded HTML would be randomly re-encoded. I am sure this is much better now.

    And then I had to add hacks to lower the number of spam comments received (having 200 comments in Spam every day was easy, but I’d like to avoid that), so I wrote a plugin. Having wandered through the internals for a while I realized I’m missing the simplicity of a static Octopress installation, where whatever you put out IS the thing that is going to be sent to the user. Roberto Alsina at that time was busy with Nikola and I decided to return to statically generated content, but with a tool written in a language I understand (python). And then yet another vulnerability was published affecting WordPress version I was running on my host.

    I’ve also had this hope of editing articles easily on my phone/tablet, but I’ve found that 1) I don’t edit things that often w/o access to my computer, and 2) formatting is brittle. The latter may have been fixed already, though.

    1. Octopress was way more complicated to customize than Nikola, and their codebase was much more complicated than Nikola’s. I only spent like a week with it before moving on to something ese. I kind of like TextPattern better than WordPress, but it still manages to annoy me way more than WordPress – so I’m sticking with the latter.

      Also, I do account for spider traffic when mentioning traffic numbers. It’s not an increase in bot traffic that is going up when I moved to WordPress. 😉 I kind of expected traffic to drop as the site did get a bit slower; however it looks like I was worried over nothing.

      Almost all the comments that come in via WordPress is spam. But the same is true for any public commenting system. Moderators just have to deal with it.

  3. Static siste generator is basically just flat files. Those can be edited on a simple text editor on phones.

    You’d need a URL to make the server do a commit+push, but surely that wouldn’t be much of a problem? On the other hand that would be a small bespoke system, while with WP and similar you’d get it out of the box.

    I’ve only ever written my own static site generators, but have mostly used either WordPress or DjangoCMS for sites. So I do appreciate the insight. On the other hand I stopped blogging a long time ago, I think the trick is actually to switch back and forth a bit to keep your tech interest as well as writing interest alive ?

    1. It’s not just about editing the static files, but also rebuilding and deploying the site. Plus, you’ll usually want to build it locally so you can preview it before you deploy the site.

      Say you’ve scheduled one article per week for six weeks. Two of those articles also need to update other articles to link to the newer articles; but only after the new articles have been published. With a static site system, you’d need to depend on multiple branches to keep track of those changes and deal with integrated merging and site-rebuilding and deployment setups. It works for like two–three queued articles, but then starts to get complicated very fast as the article queue grows.

      You should start blogging again, Oding. Share whatever interest you and write it well. Tech bloggers are a dying breed, and they’re taking the open web with them — leaving just Facebook and a few other walled gardens behind.

Leave a Reply

Your email address will not be published. Be courteous and on-topic. Comments are moderated prior to publication.