It's that time of the month again .. time to go through all my WordPress instances and run through the checklist to make sure I am not being hacked .. my modules still play nice together, databases are optimised, backups are working, customer blog posts haven't been hijacked by automated comments.
Ok, check, double check .. let me update the modules real quick. And 💥: the site is down. GREAT! Let's hope your backups are working, and you have the database credentials so your client doesn't miss any sales while you're trying to restore it to a workable state.
Deep down you know you should have done it on the UAT environment first, but that one hasn't got the right content on it, and that migration script you had going has been broken for a few months now.
Don't worry, you're not alone, this is the experience many developers and system administrators have when dealing with CMS maintenance.
Why are we doing all this work for sites that barely change?
Part of the problem with most main-stream CMSes is that their architectures centre around an application server that dynamically generates HTML when a customer visits.
Even if the site hasn't been altered in a long time, its output is regenerated time and time again.
While not necessarily a wrong approach, it does introduce a number of moving parts that all need to be online and working as expected to serve content successfully: some distributed edge caching layer for good performance, a load balancer to one or more web application servers and a database that may or may not be clustered.
Something can (and will) go wrong at each and every point of the stack. To successfully manage this infrastructure you need to have intimate knowledge of its operation, or pay for an expensive service that takes care of some of the burden.
Even then, you're still left with the actual application itself. Due to its dynamic nature, customers have implicit access to the servers running its code which means it needs to be kept up to date. Even if a customer doesn't change their site very often, you still need to manage security updates to CMS extensions, while attempting to balance dependencies they have on each other.
More often than not, at a time you'd rather not have it happen, you'll end up in a situation where something breaks which will need your immediate attention.
The other end of the spectrum is a site that is statically generated. There are quite a few excellent frameworks around that help you accomplish this. They fix most of the previously described issues; but introduce a new downside, less freedom to edit your site's content.
The content is likely some markdown files, or perhaps a twig file that lets you specify content for different layout slots.
Either way, most of the solutions on offer are much more appropriate for a technical audience, not your average business owner.
EX:OH offers the solution here: a rich visual editing experience paired with a static rendering pipeline that makes the site immutable once it reaches the cloud edge.
That’s what we mean by solid-state: the editing system stays dynamic, but the public website is published as pre-rendered files.
The way EX:OH CMS offers the best of both worlds is by implementing a high-quality visual editing experience that allows your customers to build websites using components, sections or elements (whatever you call it in your current framework) that, when published, make their way to the cloud in static form.
One last magic sprinkle is the most minimal bit of code sitting alongside your content in an edge function that will take care of redirecting from old to new URLs, so you can keep all the SEO juices flowing richly.
Not only will it nicely write static sites to the cloud, it will also:
Does EX:OH fit every use-case? No, definitely not. I probably wouldn't use it for constantly changing, highly dynamic sites (although you could integrate the static website with other services through client-side APIs); authenticated platforms; data dashboards and the like.
I suggest using EX:OH for all your regular website needs so that you can free up time to make the things that don't fit EX:OH.
So, try EX:OH today, start publishing sites, stop babysitting stacks.