WordPress Software Quality: Where Flexibility gives Way to Reliability

It is surely not exaggerated to say that WordPress is todays most popular web publishing software. I avoid the term «content management system» for a reason because WordPress is more than that. It comes with an inbuilt module browser that allows the user to highly customize its very own publishing tool in function and design. It’s no secret that this flexibility is a key part of the formula of WordPress’ success.

Maintaining a consistent system

WordPress is even able to update its own source code. This is a good thing from a users perspective as you can upgrade to a newer version by simply clicking a button on the administration interface. By default, WordPress updates itself automatically if a new bugfix release is available which is even better from a security perspective as it doesn’t leave a horde of vulnerable potential bot systems out there in the web. (Assuming the automated update mechanism isn’t vulnerable itself, of course.)

These updates (as well as updating activated themes and plugins) affecting the state of your application as they directly change the source code. Whether it’s an automatic update or a user triggered one, it works by fetching and unpacking an archive file from a remote server and then simply replacing the current source code files with the new ones using common file system operations.

During the file system operation we find the source code in an inconsistent state. That means there are already new files in place while others are still about to be replaced. It would be very likely that a visitor, that arrives the website while an update is in progress, would be triggering errors in the application and in worst case leaving a corrupted data base.

To overcome this risk, WordPress enables itself a maintenance mode (during core updates) that blocks every request by serving a short message to the visitor and immediately stops the application process afterwards. Plugins are deactivated during this update process.

A DevOps nightmare

With it increasing popularity WordPress is used more and more in «enterprise» context. (Which is a synonym for: ‹large companies with large development departments doing crazy stuff that is highly frequented in the web›.) So even large web shops are driven by WordPress these days.

Now it wouldn’t be a big deal if a personal blog is set to maintenance mode for a couple of seconds but it is no option for a site that make a turnover of thousands of Euro each day. Or imagine a service API that is driven by WordPress REST module that other services rely on and for a minute or two it responses with this:

Every monitoring tool would immediately raise an alert and one would become very twitchy in some DevOps department out there.

A testers nightmare

In professional web development automated software tests are widely spread these days. As part of quality assurance they should have a fixed place in every release cycle. It’s even better if they are running automated on every commit, we call this continuous integration. However, you make your life as developer way easier if you following the simple rule that no code should be shipped to production that was not tested.

Now imagine a high frequented news website that on the other end works dozens of editors on the content. If the software fails it would not only mean that hundreds of visitors would been left upset but also the complete editorial department can’t continue to work. Needles to say, that a guy from the sales department is a realistic thread if you leave him with the ability to install just another slider plugin from the admin interface. (No, revoke the admin role is not an option in many cases.)

So both WordPress features, automatic updates and a graphic user interface to manage components are conflicting with basic workflow principles of professional software development in the way they are implemented right now. At Inpsyde, we mostly turn both completely off. But these problems aren’t new. In fact these features were problematic from the day you started to put your application under version control or using Composer as package manager.

Update your concept

If you are planning a professional online business and consider WordPress as a platform you might either go with in-house professionals or with an external IT partner. The ability to install plugins out of a pool of ten thousands «on the fly» should definitively be not an argument pro WordPress. Of course, public available «third party» plugins can be part of the concept but only of they run through a proper testing and deployment cycle. Leave the application building in the hands of software experts.

That also means that third party plugins normally does not reduce costs («The code is already written, isn’t it?») because many of them will fail as soon as you apply a minimum quality standard such as code quality or performance requirements at larger scale. WordPress is able to drive complex, high frequented online portals, shops and API services. But it isn’t cheap at all if reliability and performance matters.