The Fault In WordPress Security Lies Not In The Updates, But In Ourselves

A recent blog post at WP Tavern says it’s time to have WordPress force plugin and theme updates to all users:

While I don’t like having my hand held by software to keep things up to date, it appears as though there is no other choice. Automatic updates to minor releases is a good first step, but it needs to auto update everything because leaving the responsibility up to users is clearly not working.

Cue the comments backlash, pointing out that which anyone who has ever administered a WordPress site for more than a week knows: Autoupdating WordPress plugins and themes will break far more websites than it fixes.

Because far too often, people need outdated (or hacked) plugins and themes to keep their sites running. Move one card and the whole house falls down.

That should have been plain to the post’s author, even before he ever wrote that piece.

But I empathize with the author’s main point: Too many WordPress installs are left to fester after initial deployment.

Really Easy To Use. Fairly Easy To Build. Nearly Impossible To Properly Manage.

Before I proceed to bury WordPress, let me first praise it.

I love WordPress because it is, by far, the simplest content management system out there. If you can teach someone how to operate a Web broswer, you can probably get him to manage content in WordPress.

And WordPress is rightly loved by site developers because skinning it is pretty straightforward, and it’s wildly extensible thanks to the plugin directory. You need know virtually nothing about MySQL, very little about PHP, and only the rudiments of HTML and CSS to build sites with WordPress.

I recently did a couple jobs for a very successful WordPress site developer, but where the lead developer couldn’t write responsive CSS, had no JavaScript experience at all, and had no apparent experience with PHP or MySQL.

Basically, they purchased a plug-and-play framework from a theme vendor and built every site with it. Which worked great, except they couldn’t do anything the framework didn’t have built into it.

I ended the relationship after two jobs because I was slogging through tedious workarounds, taking hours to make CSS and jQuery changes that would have taken 10 minutes, had they not been so reliant on a single theme framework they absolutely refused to edit.

What’s difficult in WordPress is understanding how it works, beyond operating the Dashboard.

This becomes compounded the more complex a site becomes. The more involved the theme, and the more a site relies on plugins, the more important it is for a site to be overseen by someone who understands how WordPress goes about handling requests and returning responses.

Custom Post Type UI banner from the WordPress plugins repository.
Custom Post Type UI banner from the WordPress plugins repository.

Begging The Question

What the WP Tavern blogger missed, completely, is the actual source of the WordPress security problem.

It’s not that people aren’t keeping their themes and plugins up-to-date. The real WordPress security problem is that so many sites rely heavily on code — themes and plugins — made by third parties.

A recent example of this problem came to light for me during recent update troubles in the Custom Post Type UI plugin.

Basically, this plugin lets you create custom post types and taxonomies via the Dashboard, rather than the far more complicated functions.php coding normally used.

I inherited a website some time back, in which the architect built several custom post types and taxonomies using this plugin. And it worked great, right up to early February.

That’s when the plugin author decided to push some changes to the UI, along with some other code changes, out to release. A release which I immediately applied. And which immediately proceeded to break my site’s permalinks.

I wasn’t the only one; far from it. The developer, to his credit, quickly rolled back the changes with a new version, and set about trying to fix those.

In the process, he broke more features for more users. And so on, and so on.

Since the trouble started, the developer has made four different releases, each claiming to be stable, but each breaking something that had been working for a sizable number of users. Things still aren’t right.

Let me be clear: I admire any author of a free plugin for WordPress, especially if he is providing near continuous support at no cost. That’s someone who deserves praise.

At the same time: If it ain’t broke, don’t fix it.

Just Because You Can, Doesn’t Mean You Should

Had I built that website from scratch, I never would have used Custom Post Type UI; I would have added the custom post types and taxonomy via my theme.

But again, the benefit of WordPress is, “there’s a plugin for that.” It brings fairly sophisticated programming into the reach of people who aren’t skilled coders.

That’s the actual problem. Not “if people would just update, security wouldn’t be an issue.” Instead, “if people understood the implications of their plugin and theme choices, security wouldn’t be an issue.”

The problem is:

Too many WordPress “developers” don’t understand how WordPress works.

This leads them to choose to use plugins where it’s not appropriate, to overuse plugins and to not understand how the choice of a specific plugin or theme affects the overall operation of their websites.

Worse, they tend to install any plugin that solves a problem, without considering

  • how old it is / the last time it was updated,
  • the importance of the plugin to the overall functionality of the site, and therefore the pitfalls of it going haywire,
  • whether forking a critical plugin, or developing their own alternative, is a wiser choice, and
  • if a different approach to the site’s design or architecture is a wiser path.

In other words, just because a plugin allows you to do something easily, that doesn’t mean you should do it.

Too many WordPress installs are sold as “fire and forget.”

The developer sold the website to a client. He probably even touted its ease of use as its selling point. But he never mentioned that the site will require continuous, high-level management by someone who understands that particular WordPress install.

Because the customer wanted to spend X number of dollars for a website that lasts Y number of years, without further expense, the developer effectively abandoned the site after the sale.

Sure, some of that is on the customer for pinching pennies. But it’s incumbent upon the WordPress developer, as a principled and decent human being, to at least let the customer know that periodically, every WordPress site needs to be updated, and that updating must be done by someone who knows what he is doing.

xkcd: Orphaned Projects
xkcd: Orphaned Projects

Reality Check

Let’s be real: Neither this post, nor the post at WP Tavern, is the answer to WordPress security and entropy.

Truth is, WordPress is popular for the very reasons that make it difficult to secure and keep fresh. It’s simple. It works out-of-the-box. And there’s virtually nothing you can’t get it to do using a canned theme or plugin.

But given the choice between forcing people to keep a site fresh, and accepting that a large percentage of sites will always be zombies, I’m on Team Zombie.

Ideally, all WordPress sites are managed by capable professionals who understand how WordPress works. Professionals who understand their installs, who can calculate the risks of choosing a given plugin or theme, and who can quickly recover a site when one of those third-party products goes wrong.

Ideally, every WordPress site is hosted by a provider who can help counter 0-day WordPress security threats.

Ideally, every WordPress site has a full backup solution like VaultPress or frequent snapshots.

But we know these things are not true for the vast majority of WordPress sites.

Given the imperfect world presented by the nearly perfect CMS called WordPress, I see automatic updates of themes and plugins as a nuclear option that leads to a nuclear winter on the Web.

All links in this post on delicious:

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  • Check out the Commenting Guidelines before commenting, please!
  • Want to share code? Please put it into a GitHub Gist, CodePen or pastebin and link to that in your comment.
  • Just have a line or two of markup? Wrap them in an appropriate SyntaxHighlighter Evolved shortcode for your programming language, please!