The elePHPant in the room: Wordpress

There is no denying that PHP took a great leap forward in the last years. The transformation is so generalized that “the PHP experience” has become, to many, somehow irrecognizable.

It’s hard to point at one single factor. With changes covering from performance boosts, quality-of-life syntax changes (type-hinting, PHPDoc generics) and async development (coroutines, generators), the newer versions make development feel more like the intellectual task that programming should be and less like the constant wrestling with language quirks and hacks of previous years.

Quantitatively speaking, the language still owes much of its market share to Wordpress. And that is something we do not like to talk about.

Before you stop here

Some developers cringe at the sole mention of Wordpress. I was there, too. I looked down at those poor creatures repeating add_filter and add_action like a mantra every time they needed to change something in their site.

If that is your case, I ask you a favor: give the following paragraphs a caritative read. I will make by best effort to give dimension of the problem that Wordpress comes to solve.

Why is Wordpress still here?

If you ever had to build and maintain a system where a client needs to editorialize an almost infinitely flexible content, you might be familiar with the following situation:

<Annoying client> says:
- Can I add an image to this article?

Two weeks later, <annoying client> says:
- Can we also make it possible to be a self-hosted video? And… can I make it visible only to logged in users?

Three weeks later, <annoying client>:
Sorry, it won’t be a video. Marketing changed their mind. Now they want it to be a Spotify podcast. Can we make it the same block available in the FAQs section, too? And can we add a transcription field below every podcast? Can we make it translatable?

But isn’t this common to all software?

Yes, changing requirements are no novelty in the world of software development. There are some problems, though, which are specific to content management and its inpredictability.

No matter how expert the development team declaring that Article class is, no matter the level of composition and inheritance of your codebase, it won’t be enough to deliver the changes at the pace required by content creators today.

A testimony to this is the fact that many mature CMS solutions still fall short when providing the extensibility to solve many common problems like CDN assets URL replacement, custom fields extension, role-based content restriction, etc. This is a trait of content creation that should not be overlooked when comparing a CMS to other software like a SaaS API. Building a CMS from scratch can quickly become extremely frustrating as there is so much that feels something already done, but you are still implementing it every time.

This and nothing else is the known problem that most CMS come to solve: how can a framework allow users to editorialize web-ready content with a variable structure and the least possible resistance.

And there are not a lot of good solutions out there:

Drupal / Joomla.

The lack of maintenance here is baffling. Also, they will go through the “configuration” route in the “content vs. configuration” dichotomy, leading to every solution needing tech intervention.

More boutique-like solutions.

OctoberCMS, a Laravel-based CMS, is an example of a “more dev-friendly” solution. But the ecosystem behind is way smaller. You can see something similar happening with CraftCMS, which is also proprietary, so you lose on the advantages of an OSS solution.

Proprietary cloud solutions:

There are expensive solutions like Adobe Experience Manager and Salesforce Lightning Pages that are either too big, too expensive or too restrictive to be even considered by most companies. Also, they do not offer any way of moving your site in or out without a full redesign.

No-code solutions

In terms of performance, I was surprised when I saw the results of services like Wix.com and Webflow.

These webapps allow users to create scalable, modern websites with almost zero programming. Both allow the inclusion of datasources and have some limited scripting to allow more complex behavior. Note the word limited.

However, I find that these services keep orienting towards the small business. Serious clients and developers are still reluctant to rely on no-code.

JAMstack

JAMstack plans to solve many common pitfalls of headful CMSs like Wordpress. With native GraphQL, they circumvent contract issues with the frontend. SEO advantages can be achieved through DOM-aware object hydration. If performance is a do-or-die, GastbyJS and Nuxt often deliver under ~50ms response times, thanks to building static files rather than serving requests.

But to many people, a 500ms second load time is acceptable. Even Google considers a page load time of under 2 seconds to be acceptable.

If scalability comes into play, high concurrency can be achieved by horizontal scaling. 100USD per month on an autoscaling cloud infrastructure is way less costly than an extra TypeScript dev for 120K+ a year. And for many, the improvements don’t compensate the setbacks:

• Vendor lock-in is real.
• Not a huge ecosystem. Some of these headless CMS have their “app marketplaces” only kept alive by virtue of paying customers which are a very small, not very agile, group.
• The framework will require highly qualified fullstack developers and DevOps pipelines (if dealing with huge amounts of content, you don’t want to rebuild the entire site at every change, so you need to keep track of which pages to rebuild when content changes).

Wordpress keeps chugging along

An ex-coworker who works in frontend asked me some months ago: “is there something going on with Wordpress? I see more and more of these job applications for Wordpress and Woocommerce theme design”.

Truth is: despite the constant bashing, Wordpress’ market share has kept growing. From ~15% in 2010, to ~60% in 2023. Much of this can be attributed to the collective power drawn from open source.

Community efforts tackle many of the core problems of Wordpress and CMS in general:

The arrival of Gutenberg as a block editor has been a blessing for creators. I see it every time clients rebuild complex landing pages without asking for any help at all.

ACF as a standard tool lets you extend post types, options and taxonomies indefinitely. Any complex content structure is just some clicks away with repeater fields, post to post relations, user-role based field groups, etc.

Wordpress’ REST API, introduced in version 4.4 (circa 2015), has granted a standardized, predictable way of doing interoperability with other systems. Do you need to integrate your custom Python machine-learning scoring service into your e-commerce? Sure, just hit the Wordpress API to bulk update your products.

Lastly, the impact of Woocommerce. The ability to make your bucks will always be a determining factor. Many clients find that Woo gives them a sweet spot between the low-entry barrier of cloud solutions like “Wix Stores” and the extensibility of a custom system. Thanks to Woocommerce extensions, it’s easy to set up a store with downloadable products, multiple payment gateways, shipping solutions, etc.

Lastly, I wouldn’t like to skip the introduction of Action Scheduler, which can provide a distributed queueing mechanism to implement any complex set of tasks with proper retry mechanisms and logging.

One last factor could be the arisal of many managed hosting solutions for Wordpress which have a stake at the framework’s success, making their money due by abstracting the complexity of scaling and networking. Some examples are WPEngine, Cloudways, Pantheon.io, Siteground.

What is not working

Contrary to what I consider the popular belief, some of Wordpress’ disadvantages against other CMS can be traced to PHP itself.

There is a lack of a sturdy DOM-aware templating system, something like JSX in the Javascript ecosystem. Maybe because of its origins as a CGI module, PHP has never been too concerned with the structure of the output, only with doing the output. This poses some issues when you want to implement site-wide, consistent features, like lazy-loading for images or to allow search engines to index a single-page application form.

These are not shortcomings introduced by Wordpress itself, but an endemic issue within the PHP ecosystem. It would be interesting to see what happens in these aspects in the upcoming years.

But there are many important setbacks and issues with the framework itself:

• The lack of request abstraction in Wordpress makes things impossible to be tested in a vacuum. Unit testing seems like El Dorado. You can sometimes find a post of someone doing it, but the process is so complex and custom that it feels like climbing the Everest.
• Backwards compatibility makes Wordpress feel a bit disconnected from the modern development experience. Type-hinting could help prevent many bugs by means of static analysis. There is also a lack of proper OOP practices in the framework.
• Versioning site configuration. Funny story: a plugin named Versionpress attempted to solve this some years ago, in what we can now call a heroic but failed attempt. Nowadays, you can do a little bit of versioning: ACF has added the possibility to version your custom fields via an `acf-json` folder. Also, theme.json and block.json files allow you to keep track of your Gutenberg blocks and settings.
  But many popular plugins still don’t offer any way to keep track of their configuration (templates, settings, etc) in the codebase which, during development, forces you to pull a fresh copy of the entire database if working in a team. And during deployment, it forces the introduction of manual steps that are prone to human error.

My suggestion would be that newer major versions of Wordpress make the tough decision to end support for prior versions of PHP. If your site will break if you update PHP to version 7.3, then maybe that is your site’s problem and you should deactivate automated updates. There is no need to keep the framework behind for everyone else.

Supporting these versions, even if it is with the purpose of still providing security updates, makes no sense. PHP 7.4 has reached EOL, so these sites running PHP 5.6 are still running a lot of vulnerabilities.

If we still want to keep supporting these versions, a way to achieve this could be to split security patches and framework releases (in a Windows sort-of-fashion). You now maintain two major versions: one compatible until 7.4 (maximum unsupported PHP version), and one in sync with PHP versions. If you want to keep moving forward, you must keep your PHP versions up-to-date. This is what every other piece of software on a package registry does. Keeping your infrastructure up-to-date is not so difficult anymore. There are lots of possibilities todays in terms of infrastructure to manage server updates which just weren’t available before.

Another possible improvement area would be an accessible, straightforward path to unit testing in Wordpress. Right now, it seems something that only a few people are doing.

More plugins should also commit to making their data versionable, like ACF did with the inclusion of the acf-json/ folder. Recently, I asked the helpdesk of a very famous paid plugin if they ever planned to make their configuration templates versionable, to which they replied with a very dry “no”. This attitude can push serious developers away from your product.

Conclusion. And some tips for fellow developers

I hope I provided my perspective on the situation of the CMS problem in 2023. I’m not sure where things are heading, but I think it’s important to understand where we stand.

It’s important not to oversimplify the problem: Wordpress is still popular for a reason. I still don’t see a clear alternative that fits in the gaps that it fills today. It is even probable that those might be addressed by the Wordpress ecosystem itself.

I would like to close with some recent findings or explorations I’ve been trying for Folkamedia, the agency I work for. Hopefully, any Wordpress developers seeking to enrich their workflow can find these tools interesting:

Managed HTML cache-on-edge via Cloudflare:

At least from my experience with several clients, I still don’t see HTML caching being used very often. If it is ever used, it still requires a request to the origin server.

Static HTML caching-on-edge can be easily achieved on Cloudflare via a plugin, which will hold full pages on their CDN and invalidate caches when content gets updated. In this way, you can get response times along the lines of those provided by JAMstack solutions.

If you are using Cloudways or other service running Varnish, you can achieve something similar with this plugin for managing Varnish cache.

Unluckily, I haven’t found any good plugins for doing the same on services like AWS Cloudfront or Digitalocean Spaces CDN,

Managing virtual meta fields via WP_Post and WP_User:

The WP_Postclass in Wordpress is declared as final . You can’t extend it. But you can add your own computed properties by means of a “virtual meta”. By adding a filter on get_{$post_type}_meta you can achieve some form of polymorphism for different user roles or post types, so that they can be consistently accessed, for example, via the API.

WP migrations for versioning

We are exploring this composer module by Deliciousbrains to run migrations from WP-CLI. During deployment, we automatically run any pending migrations. That can include database changes, custom code to update posts, pages, roles, taxonomies.

Plugin management via Composer using wpackagist.com

By having Wordpress installed as a composer module, you can track required plugins and themes as composer modules. Some solutions like Bedrock already provide a boilerplate for this structure.

Conditional Blocks

There is an awesome but still quite unknown plugin, with a lot of potential for more no-code control of block content. A bit too expensive, in my opinion, for a single site but worth considering for various sites: https://conditionalblocks.com/

Pre-built workflow frameworks

Solutions like Sage, Trellis, and pretty much everything by roots.io seek to provide standard workflows from development to deployment. Many of those are too opinionated for me, but could be the right tool for you.

Thanks for reading. Note I also write on Twitter (oh, right, X) about several topics, if you prefer “the shorter form”.