How to Stay in the Loop if You Turn Off WordPress’ Automatic Updates

When a critical security vulnerability was discovered in Yoast’s SEO plugin this week, WordPress.org took the initiative to automatically update users’ sites with the patched version of the plugin. Many users were taken by surprise, given that the WordPress codex clearly stated that automatic plugin and theme updates are disabled by default.

Shortly after the automatic update rolled out, the codex page was updated to reflect the fact that in rare instances WordPress.org will automatically update your plugins and themes unless you opt to turn this feature off entirely. Many users are not comfortable with forced automatic updates, but the good news is that there is a filter to turn them off, including the WordPress.org security updates for popular plugins:

add_filter( 'auto_update_plugin', '__return_false' );

Prior to this security issue, users were not aware that they had to opt out of these forced updates. On one side of the fence there are those who think it’s no big deal and are thankful that WordPress.org is proactive on behalf of user security.

On the other hand, there are those who are wary of forced updates from plugin authors who are notorious for pushing out problematic updates. The support forum for Yoast’s SEO plugin contains many threads regarding fatal errors following updates issued in the past.

In this particular case, Nick Haskins summarizes why he was not comfortable with WordPress.org’s forced update:

The plugin in question is Yoast WordPress SEO. If you’re not familiar with his plugins, the history of updates is awful. In the last two weeks, I’ve updated twice, and both times have resulted in fatal PHP errors which require FTP’ing into the site, to manually remove the plugin. Both cases were due to not checking if a file exists before loading it.

Those who are not comfortable with WordPress.org’s forced update policy have the option to turn updates off for particular plugins or for all plugins. If you opt to go the route of turning automatic updates off, there are alternative ways that you can stay up-to-date on plugin releases.

Get Email Notices When Core, Plugin, and Theme Updates are Available

photo credit: Par avion - (license)
photo credit: Par avion(license)

No site admin can realistically be expected to log into his site(s) and check for update every day, let alone follow all the news surrounding plugin and theme security issues. The WP Updates Notifier plugin will monitor your WordPress installation for updates and will send you an email as they become available. It includes the following features:

  • Set the interval of how often to check for updates; hourly, twice daily or daily.
  • Sets WordPress to check for updates more often meaning you get to know about updates sooner.
  • Get emailed about core, plugin and theme updates.
  • Chose if you want to be notified about active only themes and plugins updates.
  • Remove upgrade nag message to non-admin users.
  • For advanced users there are a number of filters and actions you can use.

It would be truly awesome if WP Updates Notifier was also able to scan a plugin’s changelog for the word “Security” and tack it onto the email if it is applicable.

WP Updates Notifier can be useful even if you’re comfortable allowing WordPress.org to perform occasional forced updates to themes and plugins for security. You may be using a plugin that is not nearly popular enough meet the criteria for a forced automatic update. Regardless, it may be useful for you to know as soon as there is an update available.

The important thing is to stay in the loop about potential security issues and get patches as soon as they are available. WP Updates Notifier lets you do that without having to allow any third party update core, plugins, or themes on your server. The plugin is most useful when you have only a handful of sites or fewer. Otherwise, it’s probably better to utilize a central dashboard service where you check in regularly to see updates across all of your sites at once.

Your other alternative is to ditch plugins created by authors who you cannot trust to issue clean updates. That will put you in a better position to leave automatic background updates on, which is recommended for the vast majority of WordPress users.

Would you like to write for WP Tavern? We are always accepting guest posts from the community and are looking for new contributors. Get in touch with us and let's discuss your ideas.

23 Comments


  1. On the other hand, there are those who are wary of forced updates from plugin authors who are notorious for pushing out problematic updates.

    It should be noted that forced security updates come from the WordPress Security Team and are tested by them, not from the plugin author. It isn’t Yoast pushing an update. :)

    Report


    1. True, but I think a lot of people are uncomfortable with receiving any kind of update, security or otherwise, from a third party without having the chance to test it first – even if it is from WordPress.org. This unusual circumstance with Yoast’s plugin really struck a nerve for a number of different reasons.

      Report


      1. Right. It is interesting that none of this fallout occurred after Jetpack did the same thing 11 months ago.

        My point is that while I expect oddities with Yoast updates normally, this one came from the Security team. It wasn’t a third-party update that was forced.

        I understand why this bothered people, but a big piece is educating folks on the process. Yoast might fatal an update, but Nacin wouldn’t. I wouldn’t turn on normal auto-updates for Yoast, but still allow minor/security release updates.

        If you don’t trust the Core team, then shutting off all auto-updates make sense. This isn’t different than 4.1.1 except the same people updating a seriously insecure plugin instead of a core file.

        Report


      2. Yes, more education is definitely needed, because the fact that Yoast’s updates often cause issues with people’s installs makes people wary of getting a forced update for one of his plugins if they don’t know the process the core security team uses. We’e yet to see anything official published on WordPress.org about this process.

        Report


      3. Sarah,

        The whole issue really stems down to user education. I don’t think people were more irritated that this was done without their consent and especially when the Codex had stated otherwise than the update itself.

        User education is extremely important to ensure people trust what’s going on. Personally, I prefer my site being secure automatically!

        Report


      4. We’e yet to see anything official published on WordPress.org about this process.

        It’s in the security whitepaper, published earlier this month, under the “WordPress Plugin and Theme Security” section: https://wordpress.org/about/security/

        When a plugin vulnerability is discovered by the WordPress Security Team, they contact the plugin author and work together to fix and release a secure version of the plugin. If there is a lack of response from the plugin author or if the vulnerability is severe, the plugin/theme is pulled from the public directory, and in some cases, fixed and updated directly by the Security Team.

        Report


      5. “the fact that Yoast’s updates often cause issues with people’s installs makes people wary of getting a forced update for one of his plugins”

        Do you have data to support this assertion, or rather, what appears to be an implicit criticism? I’m curious because it might be that updating a plugin with 1+ million active installs is bound to run into issues on some installs. Or it might be that their QA is poor. It would be nice to know which it is.

        Report


      6. trevellyan – It’s happened to me numerous times when updating his plugins. You can also view the support forums on WordPress.org to confirm that Haskins is not the only one who has experienced this.

        Report


  2. James, that paragraph in the security whitepaper doesn’t actually say that they will push it out as a forced background update.

    Report


    1. Hm, I suppose not. It read as heavily implied to me though, given the language of the rest of the paper.

      Report


      1. Specifically, it should say that even though you may not have theme and plugin updates enabled, WordPress can and will send you a forced update for security purposes unless you explicitly opt out using the filter: add_filter( ‘auto_update_plugin’, ‘__return_false’ );

        Report


      2. Agreed, though without the part about how to opt-out via a filter. A security whitepaper should never detail how to opt out of security.

        Report


  3. Of course, you can also opt out by only doing updates by FTP and never giving your user / pass to the wordpress software itself. Automated updates scare me greatly, in part because it means that there is a certain amount of access granted that I cannot easily control. It’s almost inevitable at some point that a hacker will get access through this sort of method.

    I should also say that until WordPress has true control over the content of all updates, I wouldn’t recommend it. From plugins that don’t work to themes that either have issues, don’t format correctly, or that are entirely different one version to another (byblos theme, example), automating updates in any manner is a huge risk. It may help some security issues, but on the other side, it risks causing errors or even making your sites unavailable or worse causing issues that Googlebot will toss you out for.

    Report


    1. I tried the option before that only does updates by FTP, but I ran into an issue. After I entered FTP username/password, the update process finished correctly, but then the page was refreshed and kept saying there is a new version of WP. I finally gave up and changed back to the previous way. I reported this issue and I hope it has been fixed.

      Report


  4. Sarah, I believe you and Haskins when you say you’ve had problems with updates from Yoast. I’m just uncomfortable with statements like the one I quoted earlier from the comments and the one in the article body (quoted below) based on what appears to be anecdotal evidence.

    “there are those who are wary of forced updates from plugin authors who are notorious for pushing out problematic updates. The support forum for Yoast’s SEO plugin contains many threads regarding fatal errors following updates issued in the past.”

    “notorious for pushing out problematic updates” Really? If there’s reliable evidence of poor QA at Yoast, let’s see it. As a repeated user of his plugins, I’m as interested a party as anyone.

    You say, “The support forum for Yoast’s SEO plugin contains many threads regarding fatal errors following updates issued in the past.”

    I see the same thing immediately after updates from WooCommerce, another plugin with 1+ million active installs. Are WooThemes also “notorious for pushing out problematic updates”.

    Report


    1. There are two types of problems that can occur with an update:

      1 – pure coding error, basically code that errors all of the time, which would have been noted during proper testing, and

      2 – environmental errors, where a combinations of version of wordpress, other plugins, OS, PHP, and the like come together to create errors for some.

      3 – security errors, unchecked and unsecured file handling… etc

      Generally, the problems in part 1 are the big ones. These are plugins and themes that error out directly when you use them. Because there is no real testing involved in rolling out a wordpress plugin, no testing suite against which they are run before public release, this is too often the case. I have downloaded and tested dozens of plugins from WordPress that either failed the first time I tried them, or worse yet, failed after an upgrade on a production site. It’s reached a point that I retain back copies of every plugin and theme because of these sorts of errors. Themes are generally worse than plugins, but it happens with both.

      The part 2 issues are harder to deal with. One of the main ones I have to deal with is that I generally run the newer versions of things like PHP. Many plugin authors seem to be operating on fairly old versions of PHP, and sometimes are prone to using functions in PHP which are either being phased out or no longer work in newer versions. Deprecated functions and methods, both in wordpress and in the operating environment are big issues.

      The third one is the biggest issue, and the one that I think wordpress can do a lot more to address. I think that wordpress needs to have a more strict standard when it comes to writing files, not allowing plugins to write their own files but rather requiring everything go through the wordpress API. That would mean in php, java, and all the rest all file writes would go through an API style interface rather than directly writing their own files. This would remove direct file writes from code, and would give a secondary layer of sanitizing of inputs before a file is written. While not perfect, it would certainly make it harder for hackers to turn plugins into security holes.

      Plugins and Themes are big wide open security holes for the most part. Most downloaders never check the code on a theme, would never notice a built in hack or remote include that could harm their site. This isn’t common, but with WordPress being as popular as it is, this sort of hacking is inevitable.

      Report


  5. what if the update causes a conflict with another plugin/theme? since I am not there doing it myself, it will ruin my site and I won’t know until I go to my site.

    I have 7 of my own sites I run, they all have Jetpack. It takes me no more than 60 seconds to update jetpack. Even if they all had their plugins with updates…It would take me no more than 5 minutes.

    I check my websites in the morning. how many do any you have that you can’t spend 5 minutes in the morning updating?

    Report


  6. I’m new in WordPress , but this guys can use in updates words like SELECT and DROP ?

    Report


  7. This forced update completely broke four of our clients WordPress sites resulting in the white screen of death. We had to manually remove the plugin and reinstall to fix the issue. It was only due to being regular WordPress blog monitors that we saw the update and checked all of the sites. Auto updates are good in that they fix a vulnerable site but I think we will be turning off auto updates now as a broken client site is not good.

    Report


  8. You can educate us to the hilt, but I’m still going to demand that I be allowed to test every single update of any kind before deploying it. Automatic, forced updates is a bad idea in most cases. Evil can be done by not updating, sure, but even more evil can potentially be done by forced updates installing new “unknown” problems or even hacks into everyone’s servers at the same time. Imagine what would happen if someone were to find an exploitable vulnerability in the forced-upgrade code and use it… (and don’t say it could never happen)

    Report

Comments are closed.