23 Comments

  1. Kraft

    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

    • Sarah Gooding

      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

      • Brandon Kraft

        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

        • Sarah Gooding

          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

          • Ajay

            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

          • James Huff

            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

          • trevellyan

            “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

          • Sarah Gooding

            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. Sarah Gooding

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

    Report

  3. alex

    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

    • Jeffrey

      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. trevellyan

    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

    • alex

      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. Miroslav Glavić

    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. Paul J

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

    Report

  7. Ivan

    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. James Huff

    Here’s some bits from Dion Hulse detailing the process: https://make.wordpress.org/plugins/2015/03/14/plugin-automatic-security-updates/

    Report

  9. Araba Yarışı

    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. it site http://www.arabayarisi.com

    Report

  10. Wet Apple Media

    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.

%d bloggers like this: