WordPress

I spent a bunch of time getting WordPress into a state where I could run it headless and then just a short while after I decide to switch over to Ghost anyway because it just ended up feeling like the slicker solution I guess. There were some things that annoyed me with the WordPress setup to be fair, chief among them the fact that all the images hosted there were getting copied over on each deploy which felt very wasteful even if it wasn’t time I spent actively waiting for the task to complete since it was done automatically in the background and Ghost seemed to have the more straightforward integrations to get the images hosted on some other platform so that they didn’t need to be part of the deploy process.

Beyond that, the writing process is largely similar, if perhaps a bit cleaner of a default editing view in Ghost than WordPress though that is easily enough configurable for it to not really be that big of a difference. The separation of the admin/publishing side and the published website itself is also more clear in Ghost, which means setting up the whole thing for headless operation was considerably smoother than it was with WordPress which somehow makes me trust the whole thing a bit more even if I personally didn’t run into any problems with WordPress or the setup really. To be fair, I am now slightly less reliant on any sort of plugins which is a boon in itself, since while they are one of the greatest strengths of WordPress they are also the source of many of its problems which makes me a tad more confident that the current setup will be easier to maintain than the previous one if only marginally.

This change of backend however, has also had me thinking about potentially changing the frontend as well, since one of the primary reasons I went with Eleventy originally was the fact that I could copy over the images from the backend during the deploy but as that is no longer necessary with them hosted off-site I might end up using one of the other static site generators I looked into but discarded due to them lacking this functionality. I’m especially curious about this since during my experimentation Gridsome and to a lesser degree Nuxt really caught my eye since I have had some previous experience building sites with Vue and being able to bring that familiarity in to this as well would be a nice bonus, along with their rendering fanciness really contributing to making the site actually feel a bit snappier which to me is one of the main points of using a headless instead of traditional CMS in the first place.

That project is still ongoing however, so I’ll have to update the state of it at a later date if I actually do end up switching, since to be fair for the most part Eleventy is doing its job in a nice and quick manner and there is no real need to switch—though I am ever the tinkerer, never quite satisified with every detail and always curious to test new things so that probably ends up being the primary reason I decide to test something different in the future.

So it’s been about a year since I started using WordPress instead of Hugo to publish this blog, and it’s been quite a nice experience so far. I like the editing workflow, that I’m actually reminded to certain things like specifying tags and publish date when I do press the publish button, and that I can schedule posts so I can write when I feel like writing and still end up with a somewhat regular cadence of when the posts actually end up getting shown on the site.

The sligthly less rosy part of the whole thing has unfortunately been the performance, specifically the performance for anyone else than myself since the site gets hosted locally to me. Now there are some things I’ve already done to alleviate this, like using caching in WordPress so that the pages get rendered faster and using Cloudflare in front of the site as a CDN and cache to hopefully deliver the content from a location closer to the reader but it’s still quite slow because in the end speed of light is a thing and the caches don’t last forever. Also, only the assets and not the pages themselves ended up being cacheable with the free Cloudflare plan, so the main content of the site ended up being served rather slowly anyway.

Then, at some point, I remembered looking into Ghost, which is another publishing platform which remains more focused on just the publishing part than WordPress and while looking into it again I discovered a keyword which lead me on something of an adventure: headless CMS. What this specifically means is, that the CMS part is just there for managing the content and then provides an API which a frontend of your choosing can then use in order to render out the actual site—so a greater separation of duties in a sense. Classically in publishing systems, the CMS is responsible for both the whole content management part and the presentation part but this separation of the two means one can take a static site generator like Eleventy or Gridsome, query the API of the CMS for the actual content and still generate the site statically which allows it to be deployed more easily.

Since this site is mostly just me writing for the fun of it and the more interactive parts like comments haven’t really proved that used implementing this approach for the site was something I set about exploring, and what an exploration that was. It all ended up being somewhat more complicated than I expected, partially because the WordPress REST API isn’t necessarily set up for all the functions required for this sort of thing—ended up needing to install another plugin for authentication against the API so that things like site settings could be retrieved through it, normally only the session cookie based authentication is implemented—and another problem ended up being content management since I want to then also deploy the media I might embed in posts so that they don’t end up still being queried from the WordPress server and that use-case was surprisingly unsupported in many of the static site generators I looked at, not even through plugins. Now, of course, most of them support some form of filters or mapping or the like with which I could create this functionality myself without too much trouble, but I wanted something where someone else had (hopefully) figured out the edge-cases for me so that I didn’t have to go around thinking about file I/O and the like.

This lead me to settle on Eleventy which allowed me to reach my goals with the least amount of fuss—which is kind of what it bills itself with as well, “Eleventy is a simpler static site generator”.

Once that decision was made it was a relatively simple task of configuring Eleventy to query the WordPress API in order to fetch the posts and then display them in a near identical manner to the current site, with the biggest differences being the lack of comments because the site is now static as well as removal of some of the shall we say bloat that WordPress as well as JetPack include. It’s all well-intentioned and I could remove it if I liked so this isn’t a criticism of WordPress by any means—and in the case of JetPack I even chose to include that—but it’s still nice to see the site in a somewhat leaner form than it was before.

Getting the category-pages working however, was a bit more of a struggle—mostly because I’m somewhat stubborn however (and also not that familiar with Eleventy)—because I didn’t want to end up retrieving the pages from the API twice so I needed to figure out some way of providing two different collections while only retrieving that data asynchronously once. In the end however, I just ended up retrieving the data twice since that seemed to be the way Eleventy preferred handling this usecase, and in the end it’s just text so it shouldn’t lead to all that big of a transfer anyway.

After that, I simply needed to find a plugin for WordPress that triggers a webhook when a new post gets published so that the hosting for the static site knows to rebuild, and the process is essentially complete. For this I settled on Notification since it seemed on the surface the cleanest and simplest implementation and it looked like it would likely remain supported in the future as well—always a concern when adding a new plugin.

All in all, the process wasn’t perhaps quite as straightforward as I would’ve wanted but still easy enough to get everything going after I stopped being stubborn and just used the systems that actually provided the features I wanted (Eleventy, specifically referring to the local image support) instead of considering developing plugins of my own. From what I can tell the site also feels quite a bit snappier even for me so that’s a big plus as well, hopefully it ends up serving any potential readers better as well! Regardless, it was a fun journey.