Security: All WordPress Plugins Must Do This One Thing

By 28th August 2014 April 13th, 2018 WordPress News and Updates

WordPressWordPress 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:

How quickly automatic updates can be applied.

How quickly automatic updates can be applied.

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.

Join the discussion 3 Comments

  • Keith Davis says:

    Hi Paul
    Makes perfect sense to me.

    The WordPress auto updates got a lot of bad press initially but I think that most users accept them now.

    With the recent spate of security issues with plugins, auto updates would be a good idea.

    View Comment
  • Olaf Lederer says:

    So, you say an important plugin updates should be done automatically and the plugin author has to decide which update is important. I think this is very dangerous.

    The same for WP management, one click updates for plugins and themes are dangerous too. I have a list of 50+ websites and I would never execute an updates with eyes closed (or by clicking the update all button from the WP management tool. Sure most of all plugin updates are going well, but I remember me several updates were the site suddenly stopped working.
    And your advice is to automatically update a plugin just because the author said so? Sorry, but I think your approach is wrong and could break more sites than an automatic upgrade might rescue!

    View Comment
    • Paul G. says:

      Hi Olaf,

      Thanks for your comment and sharing your thoughts on this.

      Taking your first point, that it’s very dangerious that a plugin author has to decide which update is important? Can you elaborate and be more specific on that danger?

      I believe in the article I expressed my own concerns about this, stating that plugin authors must be responsible in the updates they release as automatic updates. This is integral to the solution.

      The alternative is what exactly? The only people, at least on WordPress.org that can release updates in the first place, are the plugin authors – that cannot be changed with the current system anyway. Someone has to decide. And at some point we must start trusting developers.

      Yes, developers make mistakes, but I’d rather have the risk of mistakes than the risk of un-patched security issues.

      Regarding the danger of one-click updates for plugins and themes, tools like iControlWP facilitate the bulk updating of plugins, themes and WordPress itself, but they remove your responsibility as a WordPress admin to vet and test all updates. That is something that we can hardly ever automate, though there are ways to get closer to that. But never have I, nor would I, advocate as you say “updates with eyes closed”. I’m not saying anything of the sort.

      And yes, my advice is that WordPress plugin developers need to take responsibility for the security and safety of their plugins, and with the appropriate discipline, release security-only updates that are automatically patched on WordPress sites.

      That is a very specific piece of advice and a place where I’d really love to reach. Your interpretation of what I’ve said however is much broader and not really reflecting my intent of the article. I’ll give the article a re-read and see if I can clear it up a bit further though.

      Thanks for sharing your opinions on this – I appreciate you taking the time to do so – and sorry that you disagree with our views.
      Cheers!
      Paul.

      View Comment

Leave a Reply