Why can’t I find a CMS?

Underjord is a tiny, wholesome team doing Elixir consulting and contract work. If you like the writing you should really try the code. See our services for more information.

I’ve been trying to address this particular topic and I find it challenging. It is a topic that’s very easy to turn into a negative rant and that’s not what I like to do. If you enjoy any of the stacks I dismiss in this post, please know that is not a jab at you or your work. I have worked in these stacks and I’ve mostly transitioned away from them where they aren’t necessary. They absolutely work and can be used. I believe my reasons are good and sound, but they are specific to my values and experiences. If you have a different take-away, I’m fine with that. With that out of the way, let’s talk about Content Management Systems, or more commonly CMS.

Editor’s note: This post is a refinement of the 7th issue of my newsletter. If you enjoy my thoughts on things, know that I send a small essay every week.

A while back I worked with a WordPress site. I used to do a lot of work with WordPress and Drupal many years back. For me, as someone in the open source end of the software development spectrum, WordPress tends to pop up every now and then. Typically a business owner I’m familiar with will go, “We got a new website, it is a fresh new WordPress instead of the mess we had.”

At that point, it is already too late to provide any beneficial input, so I usually withhold my commentary. If they had talked to me sooner, a WordPress site is not what I would have suggested.

But that’s what I feel and that’s been my experience. I don’t find WordPress to be a healthy way of building a website or running a software development project. WordPress has a lot of things going for it; dirt cheap hosting with standard LAMP-stack hosts. Solid UI that any moderately adventurous user can handle by default. Easy to set up if you have some technical skills. Well-known, much loved, huge ecosystem. It is open source and has respectable accessibility. These things tick some serious boxes for many organizations.

So what’s my problem?

There are hidden costs. No one budgets for maintenance work. No one plans for having access to a developer when the maintenance needs to happen. No one knows that the PHP-version their host provides may shift under their feet and kill their site whenever their host decides to upgrade. Most small organizations do not set up backups. All editing happens live on the site, which can have enormous consequences.

It’s also incredibly inefficient. WordPress does dynamic rendering by default, taxing CPU and IO for every single page load of what is usually entirely static content. There are tons of ways of caching WordPress; all of them have their own advantages and drawbacks. Expect road bumps. There are even ways of generating sites statically, but that’s not by design. Expect even more road bumps. This dynamic nature is part of the simplicity of WordPress and also enables its massive extensibility. It was generally how web applications were built in the 2000s. And even though hosting is cheap, it is usually unreliable, generally bad, or has had its capacity overbooked. You tend to get what you pay for. Many CDNs offer free tiers that would be enough for almost any small org website. Such a typical CDN offering would make for hilariously great performance for any simple website. Unfortunately, they tend to work very poorly with dynamically generated sites. There is a lot of benefit in matching your static content with a static approach to rendering.

There are also no good ways of managing WordPress workflows for more serious projects where you might want some DevOps deployment procedures or want developers to be able to work on the config and content while publishing happens on the production environment. Why? Because content and configuration are deeply intermingled in the database. Especially when you use extensions, which is one of the largest selling points of WordPress. All this boils down to maddening database merging, or else re-doing the development work on the production environment when it is time to deploy. Hope you kept diligent notes because that’s how we do software development in 2022. This flies in the face of most good practices and involves a lot of time-consuming, stressful and manual work.

So why hasn’t this issue been solved? To my understanding, most of the WordPress ecosystem is not run on in-depth software development shops. It is mostly web agency-level businesses. Their focus is usually not on the development workflow and the average customer’s experience level is low enough that many do not see the problem. The pain isn’t great enough in the short term, either. The initial project effort is usually fine since there is nothing in production. Deliver to the client, move on. Sustainability is either not in the business model or just a minimal support deal. The businesses that produce most WordPress sites don’t have a lot of incentive to shake this up, and some of them don’t even know that there’s reason to be concerned. I didn’t when I was doing it.

So can we use something else? I don’t know of any CMS that I would consider a valid replacement. Easy to use for end-users, manageable complexity for the devs, a great CDN story, smooth deployment. Static site generators are great, but they are firmly on the nerd shit end of the spectrum. Great for devs, iffy for less savvy users. Netlify has had some hype with Netlify CMS, but it does lean heavily on inviting you to use the CMS specifically with Netlify services.

There are a few CMS:es, but the ones with the most traction hit other reservations of mine. Craft and Cockpit seem to be more modern CMS:es in PHP. Cool, make use of the well-established tech WordPress builds on and use it to try something more modern. The options I hear most about and see recommended frequently, like Ghost or the headless Strapi, are built with Node.js, which in some ways is the spiritual successor to PHP in web dev popularity.

However, PHP-based projects are just not particularly interesting to me because I don’t really enjoy working with the language and I still find the execution model with files in folders to be a source of entire additional classes of security issues. WordPress, Drupal, and Joomla have been enormously efficient sources for automatic compromise, as security issues surface and many users just don’t know how to keep all the parts updated. If you can get a bad file upload through, you often have remote code execution. I’m sure some projects avoid this, but from what I’ve seen, it is still mostly the same model. I have other, additional reservations about PHP overall, but lots of that is just taste and preference. It’s a decent enough language, but it’s not for me.

Node.js-based projects don’t spark joy for me because I’ve had plenty of bad experiences maintaining projects that live with significant Node.js module dependencies. I’ve seen it happen with Angular 1, Cordova and Ionic at a previous job. I’ve had clients with React Native apps who encountered the same issue. When left alone for a few months or years, a project like this is an iffy thing to get running again. I can’t in good faith give Node high marks for health and sustainability. So while I might say, “yeah, try one of those Node CMS options,” I would do so because I can’t find any options I can heartily endorse.

I like the ideas of the JAM stack, but I find the J to be over-represented. Javascript for frontend interactivity is fine and really the best option right now, but I don’t particularly like it for the backend. I don’t think Node is necessary to manage the C10K problem. I don’t find the event-driven single-threaded approach compelling when I contrast it to Erlang, Elixir, and OTP, with which I typically work. I prefer making efficient use of resources, and I get easily frustrated with the challenges Node can have with racing towards doing IO because CPU-bound work can introduce enormous performance issues. Those are certainly trade-offs you can make for a simpler execution model, but I don’t like them.

For most businesses where you just need a working website and the website is not your entire job, you can pay for something like Squarespace and be done with it. It’ll probably be fine. But for some orgs, having an open source stack is important, either ideologically, as a point of pride in openness, or because they want to avoid vendor lock-in.

The Open Source CMS is not a solved problem in my book. There is no choice that provides what I want. Perhaps I’m a bit niche in that I filter out on both PHP and Node.js, but I don’t believe I’m alone in that sentiment. I think WordPress won its market leader role on the basis of developer mindshare. It is approachable and effective. It will do in 90% of use cases, you can get at the innards and make it do what you need, and it provides a UI that your users will not complain about. I can’t get that with current solutions; they are either trying to be too clever and target developers to the detriment of end users, or they are not built in a way I expect to hold up in the long term.

So what are my requirements?

• Sound technical stack with a good record in reliability and security
• Creates primarily static sites for efficiency, security, and reliability
• Can be hosted with a wide variety of generic providers
• Supports implementing dynamic features in a JAM Stack manner, with APIs, etc.
• Provides a fully online admin UI for managing the content of the site in a smooth way
• Implements a thought-out way of working with both production editing and development processes
• Can be automated and “devops:ed” effectively
• Provides a decent ecosystem of at least themes and preferably extensions as well
• Offers a sound approach to accessibility
• Open source

I’ve already done one run on building something like this where I tried a particular Git-based approach which I’ve since abandoned. I think the approach has some merit but it is not easy or straightforward.

A while back I started experiments with a couple of co-conspirators on developing the backbone for a headless CMS in Elixir. It’s a slow process as we all have jobs and other silly priorities, but I’m hopeful that this approach could actually be quite realistic. The first step is to build good data fundamentals. For featureset I’m leaning heavily on my experiences with Contentful at a client where very successfully leveraged that headless CMS.

I don’t need it to have the critical mass of WordPress. And I doubt I’ll even manage to check my entire list up there. Hopefully, though, we can make something that solves my actual problems and we’ll see where I can take it from there.

Thanks for reading. If I’ve missed some solution that you think I should consider, or if I’m wrong about something I wrote here, don’t hesitate to write at me via lars@underjord.io or on Twitter @lawik. I’m always open to discuss what I’m up to. It would be incredibly convenient to be wrong and not have this problem anymore.

If you want more of my more frequent writing on tech, Elixir and creating things I suggest the newsletter.

Underjord is a 4 people team doing Elixir consulting and contract work. If you like the writing you should really try the code. See our services for more information.

Note: Or try the videos on the YouTube channel.