Security: All WordPress Plugins Must Do This One Thing

WordPress has included integrated Automatic Background Updates since WordPress v3.7 was released.

We’ve talked about it before, and we’ve provided tools to manage these both from within iControlWP itself, and our WordPress Shield Security plugin.

However, in this article, we’d like to share what we feel should be a critical addition to all WordPress plugins – Automatic Updates for minor releases.

If after reading this article you agree with how important a feature like this should be, please share it with your favourite WordPress plugin developers.

How WordPress Automatic Background Updates Work – an Overview

Automatic updates are quite simple really and have 2 separate stages that work off the WordPress “Cron” – a timing scheduler.

1. WordPress checks for available updates and stores this information
2. WordPress automatic updates runs, loads available updates, and based on certain directives, silently and automatically applies updates

The important point to note here is the the phrase “based on certain directives”.

What are these directives and can they be altered?

Yes they can, and it’s very easy.  WordPress has its own default automatic updates directives, and some of these are:

• Automatically update WordPress minor releases.
• Don’t automatically update WordPress major releases.
• Don’t automatically update WordPress plugins.
• Don’t automatically updates WordPress themes.

This means, by default, WordPress plugins (and themes) are never automatically upgraded to the latest release.

This is really as it should be.  However, what if all you need to release is an update to address a critical bug?  What if it’s an update to address a security issue? Wouldn’t you want your plugins to be upgraded automatically for you?

Of course, if there are functionality changes, or an upgrade will change a plugin significantly enough to disrupt site configurations, you wouldn’t want those updates applied automatically.

How WordPress Automatic Updates Work For Plugins – a technical examination

The WordPress development team have kindly offered very granular control of the WordPress automatic updates system – though admittedly restricted only to developers.

When the automatic updates process runs on plugins, there is a filter in place that says:

• There is a particular plugin update available.
• Here is the info of this plugin.
• Would you like to automatically update this?

By default, as we covered earlier, WordPress says “No”, and no plugins are updated.

But there is a WordPress filter in place to cover this, and this is exactly how it looks:

$update = apply_filters( 'auto_update_' . $type, $update, $item );

In this case, the $type is “plugin”. And $update is a boolean. Since WordPress says “No” to plugins, previous code logic has already set $update == false.

If all you do is add a filter to “auto_update_plugin” and return “true“, you will create a new directive to WordPress that automatically updates all WordPress plugins, all the time.

But we don’t want that.

WordPress filters are super flexible here and you can also use the 2nd parameter, $item. This is where the key lies to providing very specific, tailored, automatic updates for your plugins.
$item, in this case, is an object that specifies the new update info, and for which plugin exactly it is for (more on this in the code example below).

So rather than add a filter here that returns true all the time, you can add a specific filter that returns true based on particular plugin information – and any other rules you specify.

Applying Automatic Updates To Minor Releases For Plugins

There are 2 things required to make this possible:

1. Developer Discipline – you must promise yourself that you’ll only ever release bug and security fixes into minor releases
2. Code – as shown below.

Important Points To Note

• The first line that uses plugin_basename( __FILE__ ); must be in your main plugin file since it uses __FILE__.  If it isn’t there, this will not work.
• I used $global for simplicity’s sake, but you can structure it however you want within your plugin. It doesn’t matter.  All that matters it that it runs, that you can access it, and that it’s executed the main plugin file.
• I’ve assumed you understand how WordPress filters work – the function you add to the filter must be publicly callable.
• The code here works only with WordPress 3.8.2+. Why? Because Nacin introduced a significant change in WordPress 3.8.2 where they now pass an object through the filter for the $item, whereas from WordPress 3.7 -> 3.8.1, they were passing a string that was the plugin base file path.
• I have reference 2x functions called “getCurrentPluginMajorVersionNumber()” and “getNewUpdateMajorVersionNumber()”.  I can’t write these for you – this is dependent on how you structure your plugin versions system. You will need to decide how you break up a plugin version into it’s constituent parts: major and minor.
• The logic for returning boolean true or false on the equality of the version numbers is basically saying: If the major version of the current plugin is the same as the major version number of the available update, then the available update must be a minor version increase.  So return true to indicate that automatic updating should proceed. Otherwise, it’s a major version update and false is returned.

Real world example

Last week we released a bug-fix for our Twitter Bootstrap CSS plugin. It wasn’t a serious bug in this case, but it was filling up error_log files and this was messy.

The picture below shows just how quickly our plugin update was adopted.  If you look back on the previous stats, you’ll be able to see where previous updates were released with small spikes in downloads.

Imagine if this was a security release and how effective releasing a patch can be:

Why is this so important?

We believe all plugins should employ this approach and we’ve started to slowly move this into all of our plugins.

Anyone remember the horror that is the MailPoet security flaw that Sucuri published?  If MailPoet had this feature, they could have released the patch under a minor release and almost everyone would silently update with the fix.

This approach requires discipline on the part of WordPress plugin developers to not push out functionality and feature releases into minor updates.

The WordPress Shield Security plugin has had integrated Automatic updates for many months now and it works really well.  This particular type of plugin demands this type feature because it is itself security plugin and it will automatically upgrade major and minor releases – though we offer the user the option to turn this off.

If you feel this is important, again, point your WordPress plugin developers to this page and ask them to implement this as soon as they can.  The sooner more plugin developer employ this approach and take full advantage of the WordPress automatic updates system, the safer we’ll all be.