WordPress: The Application Framework You Shouldn’t Be Using

WordPress is the most popular content management system on the web. It is estimated that 40% or more of all websites are running on some version of WordPress. To put a rough number on it, that’d equate to somewhere north of 30 million websites; a massive number.

WordPress is certainly good at what it does. It allows multiple authors to rapidly and easily create and maintain consistent website content. It organizes and displays those pages and posts, and it automatically adds computer-friendly snippets of code to make that content more easily accessible, searchable, and shareable.

At Envy Labs, we build custom software in Ruby, Elixir, JavaScript, Go, and more. Yet, the site that you’re reading this article on right now – the Envy company website – is powered by WordPress. It may sport a fancy, custom, company theme, but the application itself is a basic, self-hosted WordPress application with about a dozen plugins for information submission, marketing, and security.

While WordPress isn’t perfect – it doesn’t have collaborative editing like Google Docs or native single sign-on integrations – what WordPress provides out-of-the-box is impossible to cost-effectively replicate. WordPress is good enough that the return on investment for replacing or rebuilding it just isn’t there and I would be remiss to suggest otherwise.

WordPress is a great solution for underpinning simple informational or marketing websites, like this one. Presenting photos, restaurant menus, articles, case studies, or even capturing simple contact information from site visitors are all well within WordPress’s core competencies.

That’s what WordPress was built for and is reasonably good at. However, more often than we’d like to see, WordPress is manipulated and extended to support a wide variety of other needs; often to the detriment of the system and the business.

WordPress is Easily Misused

We often see WordPress used in unintended ways – well outside of its Content Management System role. This tiptoeing off of WordPress’s golden path leads to a fragile and often perilous journey filled with endlessly cruel surprises. It is not and should not be considered as a foundation upon which to construct a solid, lasting business.

We understand that it’s not often a conscious decision to build a business entirely around WordPress. It’s often arrived at over many successive small decisions. What starts as a marketing site to gauge product interest soon adds form submission. Logins and account management quickly follow. From there, an ecommerce system gets added to monetize the audience. The server and hosting investments have already been made and the developers are already familiar with PHP and WordPress. In many ways, evolving a WordPress site feels like the simple, obvious solution; especially when a plugin is available to do what you need. But, now you’re trapped. Having invested many thousands of dollars and years of effort, you find yourself staring at a sign that simply reads, “the trail ends here.” You’ve reached the end of what WordPress can reliably offer.

Whether you use WordPress as intended or try to extend it beyond its original design, there are countless troubles to be aware of. Understanding the strengths and, more importantly the limitations of WordPress and the side-effects of relying heavily upon it are necessary in order to avoid significant – and oftentimes disastrous – repercussions.

The Ubiquity of WordPress is Also a Problem

With millions of websites running on WordPress, finding a single vulnerability in the core framework or a popular plugin can immediately unlock thousands of servers. Individuals and teams spend entire careers finding such problems to either exploit themselves, report for rewards, or sell to others for use.

In 2018, a single vulnerability found in WordPress’s XML-RPC implementation paved the way for hackers to create a self-replicating botnet of over 20,000 WordPress sites. This isn’t an outlier; there were 17 other reported vulnerabilities in WordPress in 2018, 4 of which allowed for arbitrary code execution on their servers. 23 vulnerabilities were reported in 2019. And another 21 in 2020.

Since 2004, WordPress has averaged 20 new vulnerability disclosures per year. On average, four of those disclosed per year allow for arbitrary code execution or denial of service. Clearly, security and robustness were not goals of WordPress from its outset. Although, it has certainly been forced to face and address those oversights as years pass and adoption has grown.

Needless to say, it’s paramount that if you run PHP or WordPress on your servers, you must keep your server software updated. More than most, WordPress is not a set-up-once-and-be-done system. It requires forever and ongoing security updates and maintenance to avoid a rude surprise or sudden catastrophe.

This leads to the first architectural failure of WordPress, update at your own risk.

WordPress Upgrades Are Always Risky

WordPress is under continual development with new features and functionality regularly being added and released. But ignoring that, with just the numerous vulnerabilities being identified and published, it’s demonstrably necessary to continually update your WordPress application or risk losing everything.

The official Updating WordPress guide starts with: Back up WordPress. This involves creating a database backup, as well as cloning the entire WordPress file system on your server to “somewhere safe.”

WordPress stores every post, comment, and link on your site in the associated application database. However, every image, video, or asset uploaded to a post has instead been written to the server’s file system. This will become a problem later.

After a backup has been made, updating WordPress can be as simple as clicking a button. That is, if you find it acceptable that arbitrary code is downloaded, installed, and executed on your live server without you first having a chance to inspect or validate it.

This new code wholly replaces the previous WordPress application code and simultaneously modifies the live, running database to match that which is necessary for the new version of WordPress installed. Again, these are modifications which you can’t see or validate when taking the officially suggested one-click upgrade approach.

If you have any custom code utilizing previously available WordPress functions or data or, like most everyone, you have any WordPress plugins installed, then you may have just unknowingly broken some or all of those integrations. Your live site may no longer be live. Worse, it may still be running but with major portions of functionality broken.

WordPress Plugins Have Great Power Yet Take No Responsibility

WordPress plugins are just a collection of arbitrary PHP code with some optional ties into WordPress actions and events. WordPress does not define a rigid “Plugin API” in the sense that it limits what plugins can or cannot do. This makes plugins incredibly powerful, but equally just as brittle.

Every WordPress plugin written makes some number of assumptions about the WordPress framework it operates in and the database structures available to it. These assumptions are based on documentation and observations made at the time the plugin was authored.

As such, a plugin written to work with WordPress 5.6 will very likely work after an upgrade to WordPress 5.6.1. It will also likely work with a WordPress 5.6.4 upgrade. But, that optimism diminishes when upgrading to WordPress 5.7. And later, it’s non-existent for a WordPress 6.0 release. As time marches on, the framework changes and the assumptions around which the plugin was created are less and less likely to continue to hold true.

To somewhat reliably upgrade WordPress, you must not only trust the WordPress upgrade itself, but you must also trust that all of the installed plugins have also been tested and validated against the new WordPress version. If any one of them fails the plugin may quietly cease to operate or prevent the application from running altogether. The more plugins you have installed – which can easily grow to encompass many dozens – the less likely it is that an upgrade will not result in some unexpected, breaking change.

WordPress simply isn’t architected to address, let alone solve, this problem. There isn’t always a clear delineation of public and private methods or data structures available to developers. There’s very little tooling available to plugin authors to ensure that they’re building software that will continue to correctly function across releases. It’s ultimately up to each developer to manually and continually test and validate their code against every current and future release of WordPress to ensure compatibility.

Further, just as WordPress itself has many published and exploited vulnerabilities, so too do WordPress plugins. In fact, there are exponentially more vulnerabilities found and published for plugins than there are for the core WordPress framework, due to the vast numbers of plugins and ultimately the lack of quality of their implementations.

All of this is compounded by the fact that sites often utilize plugins to extend WordPress to behave in often complex, new ways. Where once the site was a simple CMS, it may now be an ecommerce application via the WooCommerce plugin, for instance. Inventory management, credit card processing, order fulfillment, and more are now managed and maintained by a series of WordPress add-ons.

At this point, if an upgrade to either the WordPress application framework or the plugin introduces incompatibility, the stakes are now much higher due to the increased criticality of the newly provided features – especially when payments or even medical records get involved. Customers are very quick to become upset when money or privacy is on the line.

WordPress Is Not Built for Testing or High Availability

Out of the box, WordPress is not built or configured to run reliably across multiple active servers. Multi-server clusters are a standard approach to creating highly-reliable and highly-available server environments, because if one server or data center fails, everything is still up and available running elsewhere.

Between keeping code updates in sync across servers to sharing uploaded files and assets between servers – I said this would come up again later – WordPress just doesn’t natively support a highly-available environment out of the box.

Of course, there are mitigations. You can configure a network shared drive to keep assets in sync. Or more commonly, you can install plugins which change many of the offending behaviors. But then you’re only treating the symptoms rather than the underlying architecture problem, while introducing yet more fragility to the system.

Additionally, because WordPress stores its configurations in the database, it’s next to impossible to create reliable, testable, and consistent WordPress environments. In software development it’s common to have working branches of code, automated testing, a QA process, and an automated production release flow. Implementing these standard practices with a WordPress code base just isn’t straightforward, if even possible given a site’s configurations.

For example, you cannot create a staging environment, where upcoming code changes may be tested or validated, which can then be directly promoted to a production environment. While an automated solution can get fairly close to managing this migration, there’s always some manual process required. The promotion to a running production system is more complicated than just copying the code changes. It also involves merging the database changes, a problem that is not simple to solve.

So, nearly everyone seems to resort to just editing live code and changing admin panel configurations directly on running production servers. This fingers-crossed approach to software development is ludicrous. Yet many businesses accept this behavior as the status quo and have become blind to the wholly unnecessary risks they take with every change.

Finally, developers who have created applications any time in the past decade should be familiar with the concepts of building a Twelve-Factor app, whether they recognize the name or not. These twelve considerations lead to consistent, testable, and reliable software. These are features that all software must provide, yet WordPress and most available plugins, follow very few, if any of these practices.

Avoid Building Your Digital Product or Service on WordPress

Ultimately, business owners simply want a reliable and consistent experience for themselves, their staff, and their customers. How they get there is a balance of those needs against the realities of budgets and timelines. The trick is to find or create the best solution possible with the needs and limitations at hand.

When an investment has already been made – correctly in many cases –  in creating an initial site on WordPress, it can appear like a smart or safe approach to continue to leverage that existing investment to expand business features and offerings. Making small changes, like adding a few WordPress plugins, can feel risk-free and trivial in isolation. This is compounded when there isn’t a clear picture of the long-term goal of the site, or a complete understanding of the impact and criticality which the application has on the business’s bottom line.

Don’t get trapped. Step back and re-evaluate the approach. Once your business has moved beyond only needing a “here’s who we are and what we do” marketing site, it’s very likely also time to move away from WordPress toward a better, more robust, more stable, and more purpose-built software solution.