I build websites for a living. Lots of them. These websites are designed by a team of designers who design complex, bespoke, heavily branded layouts. I take those designs and my team of developers and I turn them into corporate websites, generally for medium sized industrial clients.
Sometimes the websites are big brochures, sometimes they have complex functionality. Sometimes both. They run to hundreds of pages and posts, composed of multiple layouts, templates and using, typically, 20 or more discrete modules, each configurable in multiple ways by the end user when the sites are ultimately turned over for the marketing staff of these mid sized companies to edit.
Many of them use WordPress as a CMS. From the beginning this has felt like a hack – WordPress is, and always has been a blogging platform at heart, reasonably good at what it does, providing an easy to install means for bloggers to publish simple, text heavy content without much friction. Like this very blog, for example.
It has always been an opinionated piece of software, and using it as a CMS has always meant chafing against Automattic’s assumptions about how and why their software is used.
It was a hack, but it was preferable to the alternatives. When I started using WordPress it was 2012 and the market was full of lumbering, buggy and expensive ‘Enterprise’ CMS ‘solutions’ that made fast and clean, code-driven development a nightmare. Drupal was, and still is, a clunking monster, unfriendly to developers and editors alike (that’s a whole other post). Joomla? Magento? Get outta here. WordPress offered a relatively simple and intuitive editing experience and over time it has become so ubiquitous that its very familiarity to editors is a massive selling point.
With all that in mind, the fundamental thing to remember here is that, as a professional web developer, you are building a website. A website for your client, with no limitations on presentation and functionality. A website that happens to use WordPress to provide a way for editors to add content easily. You are not building a WordPress website.
And the thing was that, once you understood the distinction, with some skill and experience you could actually make this work very well. You would write and structure your theme from scratch, ignoring bloated off the shelf themes and unwieldy child theme architectures. You would build with grunt/gulp/webpack as a build system, in a version controlled repository. You would keep concerns as separate as possible, keeping the amount of logic in templates to an absolute minimum. You would use ACF, especially its flexible content fields, to allow you to add repeatable and repositionable content in specific areas of your website. You would understand that the WordPress advocated practice of deferring functionality to plugins and using child themes only makes sense when building a simple blog type site where the theme can be swapped at will by the editor. It seemed like coexistence was possible.
And then along came Gutenberg, and it became clear that WordPress was preparing to pull away from this use case completely and move the platform to a fully fledged site builder. I’m writing this as WordPress 5.9 is released, bringing with it FSE – Full Site Editing, and this confirms that we’re at the end of the road.
Here’s an enthusiastic appraisal from the Yoast Website:
Full site editing (FSE) is a huge development for WordPress. (…) The upshot is that you have more control than ever over the design of your site. And you don’t need to mess around with any code; it’s all ready-to-use, out of the box. You can play around with site-wide designs and styles, making big changes or tweaks — and updating all of it with just the push of a button. Pretty neat, right?
The thought of client side marketing interns ‘play(ing) around with site-wide designs’ should make the blood of any professional run cold. Sites that have been painstakingly, designed and built, reviewed and refined to the last detail every step of the way with stakeholders on the client side, optimising UX, legibility, performance and upholding the client’s brand can now be squelched in an instant by someone 3 months into their job who prefers yellow.
No doubt we could work up a system to prevent this, we can restrict access and force use of the classic editor etc, but that’s where the ‘complicated futility’ comes in. It’s one thing to find a way to cherry pick aspects of the software to serve your purpose, it’s another thing entirely to try to build in complete opposition to it.
WordPress are doing what’s right for the use cases that they see as important, and that is entirely valid. They’ve decided on the best direction for their software, but it’s no longer viable for me, and those like me, to waste resources fighting the inevitable.
I’ve been building on the dev friendly, clean, code-first by design but easy to edit Twill for some time now, and although lacking in good documentation, it’s a great tool that is built with the use case of a professional developer in mind. There are, mercifully, plenty of other options out there in 2022.
The best thing about banging your head against a blogging platform for 10 years is when you stop.
I’m @coderjerk on Twitter. Check out my PHP Twitter API v2 client – Bird Elephant!
17 responses to “The Complicated Futility of WordPress”
Nice article. Agree completely.
Interesting to hear others say it. I have developing in WordPress and spent the last 3 years fighting the WP to get basic functionality to work quickly. When it works, it’s great but it’s very easy for someone else to break. Add a pluggin – oops! Styling – oops!
Everyone knows how to use a WYSIWYG editing box, maybe we should hand code with laravel or symphony!
It’s a nice article. I think for WordPress, there’s a lot of change, but at its core, it’s a blogging platform.
Check out ClassicPress. It’s a fork of WP 4.9.
You might want to check https://www.classicpress.net/ out.
Hey @codejerk, have you ever wondered looking at TYPO3 CMS ?
I haven’t looked at this one.
Yes, WordPress is not for blogging anymore. It is now harder to use. Looks like it is in between a blog & a site builder (bloated) like webflow/WIX
Hi Dan, we use WordPress exclusively (mostly with the Divi and Elementor Builders) and with all its limitations find it to mostly suit our clients’ needs. I am however wondering, with Twill, will you still be able to design a website on the backend with very limited coding involved, or would you need to know and extensively use code? I am asking, because when we hand over websites to clients we offer training to them to be able to manage their websites themselves. This is a requirement when you design websites for small and some medium sized businesses as they can’t afford the monthly fees of developers to maintain and keep their website updated. Your response will be appreciated.
Hi Kim, Twill is very much geared towards developers. Clients can manage the content and build layouts themselves in an intuitive user editor and there is objectively less to maintain but to add new features they would need a developer. Its not for everyone, but it very much suits the kind of sites I build.
WP is now developer unfriendly. It is sad… (
Block editor was not a bad idea at first look. I was thinking, it will replace heavy shortcodes usage. But now it is a mess!
CraftCMS is a wonderful alternative if this post resonates with you.
We confronted this long ago and moved to dnnsoftware.com (asp.net)
Back in 2013 I needed to build a very specialized web site for electronics assembly. I decided on WordPress as nearly every behavior could be overridden which I needed. I made it work with a simple bootstrap-based theme. Now it is looking like a web site written in 2013. I’m looking at doing a big refresh, but I think I’ll stick with WordPress as the underlying APIs don’t appear to have been that majorly mucked-with and the level of effort to shift platforms would be too high.
Very Nice Information
But Old Classic WordPress Editor Tool Way Better Than New…..
Have a Good Day
It’s C#, built on .Net MVC, which might put off PHP people, but it’s highly customisable and not at all opinionated. Would recommend.
I agree, but it’s still a 2 minute fix to simplify content editing for the client and protect the design and performance of the website. Just install disable Gutenberg, hide the default editor and use ACF fields to control what should be editable on the site.