WordPress.org

Make WordPress Core

Updates from Dion Hulse Toggle Comment Threads | Keyboard Shortcuts

  • Dion Hulse 1:40 pm on March 14, 2015 Permalink  

    Plugin Automatic Security Updates 

    Just a quick note that I’ve published an overview of the background updates for plugins over on the Plugin Announcements blog – https://make.wordpress.org/plugins/2015/03/14/plugin-automatic-security-updates/

    If you’re a plugin author, and not following that blog, now would be a good time to head on over and subscribe :)

     
  • Dion Hulse 3:35 am on September 24, 2013 Permalink
    Tags: ,   

    Automatic Core Updates, an update 

    Over the last few weeks I’ve been working on bringing Automatic Core Updates to WordPress 3.7 through #22704, Up until now it’s been disabled in trunk while development in progress – today however, that all changes.

    As of [25598] WordPress 3.7+ installs will begin updating themselves without the need of user input every time a new security release has been released, or in the case of all us development users, it’ll update daily to the latest nightly if possible.

    Automatic Updates are unattended, and by default, will only update WordPress to security releases (for example, from 3.7 to 3.7.1, but not from 3.7.1 to 3.8). Great lengths will be taken to ensure that no site will break as the result of an Automatic update.

    Note: Filter and constant names may change pending feedback and discussion.

    Edit, October 18: WordPress 3.7 RC1 changed some filter names. This post now reflects the latest names. AUTOMATIC_UPDATER_DISABLED does not work in RC1. This is fixed in 3.7-RC1-25851.

    In order for Automatic Updates to be enabled, there are a few simple requirements:

    1. If the install uses FTP for updates (and prompts for credentials), automatic updates are disabled
    2. If the install is running as a SVN or GIT checkout, automatic updates are disabled
    3. If the constants DISALLOW_FILE_MODS or AUTOMATIC_UPDATER_DISABLED are defined, automatic updates are disabled
    4. If the constant WP_AUTO_UPDATE_CORE is defined as false, automatic updates are disabled
    5. Your WordPress install also needs to be able to contact WordPress.org over HTTPS connections, so your PHP install also needs OpenSSL installed and working
    6. Wp-Cron needs to be operational, if for some reason cron fails to work for your install, Automatic Updates will also be unavailable

    We’ve also been working on a bunch of related features to make updates even more bulletproof than before, including HTTP, Filesystem, and File verification enhancements, amongst many other things.

    How do I test it?

    If you’d like to test this out, the simplest way is to simply create a new non-svn checkout of trunk and visit the site regularly to make the cron task run.
    If you’d like to test this out, and you’re running SVN/GIT, you can use add_filter( 'auto_upgrade_ignore_checkout_status', '__return_true' ); in a mu-plugin to make it ignore the checkout status, note, that you’ll lose any modifications you’ve made to core files.

    After each update, you’ll receive an email with a summary of the actions taken, which will let you know if the upgrade completed, or encountered any problems – the emails are still a work in progress, the email currently in trunk is designed for developers, and may not be the same in the final release.

    I don’t like the sound of this, How do I turn it off?

    1. If you’re using a deployment system that uses SVN or GIT, it’s disabled by default
    2. The simplest way to disable it is to add define( 'AUTOMATIC_UPDATER_DISABLED', true ); to your wp-config.php file
    3. You can also make use of the auto_upgrader_disabled automatic_updater_disabled, or, auto_upgrade_core auto_update_core filters

    Are there any more hidden features?

    This is WordPress we’re talking about, of course there’s a bunch more that it can do!

    1. If you’re using a non-English install, this will also automatically update any plugin/theme Language Packs which are installed, hopefully resulting in a better i18n experience, See #18200 for more information on Language packs, there’ll be a follow up post in the near future explaining how and when Language packs will work
    2. Plugin & Theme Updates! – You can hook into the 'auto_upgrade_plugin' or 'auto_upgrade_theme' 'auto_update_plugin' and 'auto_update_theme' filters to enable auto-updates of one, or many plugins/themes note: Plugin/Theme updates will not be enabled by default in WordPress 3.7
    3. By default, Core Auto-Updates will only apply to WordPress Security & nightly releases, that is, from 3.7.0 to 3.7.1, 3.7.1 will not automatically update to 3.8.0 – This can however be changed,  you can simply add define( 'WP_AUTO_UPDATE_CORE', true ); to your wp-config.php file and it’ll happen automatically!

    What can I do to help?

    Please test it out and report any bugs you find! Triggering automatic updates can be a little bit difficult since it currently relies upon a twice daily cron job, so the easiest way is to just create a new nightly install and visit the site once a day to cause the cron to be initiated, If you’re game to run it on a production site, please be aware that WordPress will go into Maintenance mode during the upgrade.

    You can also head over to Trac and check out report/48, which is a temporary 3.7 report containing anything related to automatic updates and Language packs (more on that in a few days)

     
    • Joseph Scott 3:43 am on September 24, 2013 Permalink | Log in to Reply

      One small thing: AUTOMATIC_UPDATER_DISABLED is an odd constant name. I thought at one point we were going to stop using negative options.

      I would have expected something more like define( 'AUTOMATIC_UPDATER', false ); instead.

      • Dion Hulse 3:47 am on September 24, 2013 Permalink | Log in to Reply

        That constant was actually inherited from the Automatic Updater plugin. The WP_AUTO_UPDATE_CORE constant is the best one to use to disable core updates, but that doesn’t affect Languages, Plugins, or, Themes.

        I should’ve mentioned it above, but Constants and Hooks are not finalised and probably will change before final release, so feel free to head over to #22704 to give some feedback

      • Franz Josef Kaiser 9:55 am on September 24, 2013 Permalink | Log in to Reply

        Just some thoughts: AUTOMATIC_UPDATER_DISABLED really isn’t the best naming decision. Hope that changes to something that’s telling more precisely what exactly will or won’t be updated if that is set to true. I’d also prefer to get all the WP constants prefixed with WP_. Even ABSPATH isn’t a unique constant in PHP world and can cause conflicts.

        Another thing that would be nice is to have an argument on the filters: Theme or (mu-)plugin name. So authors can exclude their plugins or themes from updates as easy as possible – think about alpha or beta releases and testing candidates.

        • Dion Hulse 10:29 am on September 24, 2013 Permalink | Log in to Reply

          All of the filters pass a) What it is (core, plugin, theme, language), and b) the details about the update + slug, upon re-checking, there are a few that don’t pass as much context as they could (‘auto_upgrade_ignore_checkout_status’ is the first one i noticed) which I’ll get updated.

          This post didn’t actually cover all of the filters included either, there’s a bunch more in there at almost every logic statement, you can even opt-out of receiving a summary email after the upgrade is completed. Closer to release time once all filters/constants are locked down with their naming, we’ll update a codex page, or make a post, or something :)

          I’ll get a list of filters / constants up on the Trac ticket tomorrow and let a discussion evolve over naming from there.

          • blogjunkie 1:05 am on October 23, 2013 Permalink | Log in to Reply

            Dion, any news on that Codex page with the list of filters & constants?

            • Dion Hulse 1:19 am on October 23, 2013 Permalink

              Most of the filters and constants mentioned in this post have since changed (both in naming, and what they actually do), as recent as the last few days.
              A follow up post / codex page will be made in the near future.

          • blogjunkie 4:51 am on October 23, 2013 Permalink | Log in to Reply

            Thank you!

    • Shapeshifter 3 4:02 am on September 24, 2013 Permalink | Log in to Reply

      Howdy,

      I’m been using this plugin from Gary Pendergast: https://wordpress.org/plugins/automatic-updater/ for the past week or so, and really like it.

      Should I now uninstall it, to prevent conflict or duplication of code?

      Will I still have the options to turn on/off updating of themes and/or plugins?

      Will the plugin be discontinued?

      • Dion Hulse 4:07 am on September 24, 2013 Permalink | Log in to Reply

        There should be no conflict between core and the plugin, that being said, the plugin is mostly superseded. @pento will be able to let you know the future of the plugin, I suspect it may end up as a UI for the core features rather than implementing them itself though.

        There are no built in options in core to enable automatic updating of Themes / Plugins at present, only filters (Which i’ve been using for all my testing). A plugin can easily enable it as needed.

        To enable Automatic Updating of Plugins and themes, I use this code in a mu-plugin:

        // Upgrade Plugins and Themes
        add_filter( 'auto_upgrade_plugin', '__return_true' );
        add_filter( 'auto_upgrade_theme', '__return_true' );

        • Gary Pendergast 3:20 pm on September 24, 2013 Permalink | Log in to Reply

          As @dd32 suggested, the plugin will live on as a wp-admin UI for the update options, and perhaps some advanced options, too.

          If you’re comfortable using @dd32‘s mu-plugin, there’s no need to keep Automatic Updater installed.

          • Trifon 9:06 pm on September 24, 2013 Permalink | Log in to Reply

            If the plugin will stay to provide a UI for the function, I’ll stick to using that in favour of the trimmed down mu version.

    • lgladdy 7:05 am on September 24, 2013 Permalink | Log in to Reply

      In production installs for clients, we use DISABLE_FILE_MODS to stop them being able to break things too much.

      is there a way to enable automatic security upgrades, but keep the user from doing anything manually?

      • Dion Hulse 7:24 am on September 24, 2013 Permalink | Log in to Reply

        For the record, I accidentally referred to DISALLOW_FILE_MODS as DISABLE_FILE_MODS in the post (and the code), both are now corrected.

        However, at present there isn’t a way to have both the constant defined, and allow the automatic updates.
        DISALLOW_FILE_MODS is designed for a scenario where WordPress is being used in a Deployment environment, in that environment you don’t want any file modifications to take place to core files, as such, it disables all updates (+notifications), plugin/theme installs, and plugin/theme editors.

        Disabling Plugin updates is potentially worse than not having core updated, although both need to be kept up to date, plugins are also often exploited due to vulnerabilities.

        If you just want to disable the Plugin/Theme editors, and leave updates/installations alone, you can use the DISALLOW_FILE_EDIT constant instead, if you want to get rid of all user-facing update notifications, prevent installations, etc, then you can also make a custom User Role which lacks the capability to perform those actions.

        Also worth noting, #25219 which aims to re-enable Update notifications (but not updates) for users who have DISALLOW_FILE_MODS defined.

        • RicaNeaga 7:27 am on September 24, 2013 Permalink | Log in to Reply

          Why should users be forced to look into the code for this? Of course it’s easy to add, but still… why not an option in the settings? Something like ”Enable Automatic Updates? True (default) / False” :)

          • Knut Sparhell 9:07 am on September 24, 2013 Permalink | Log in to Reply

            1. Users are not forced to look into the code. There will be plugins for this, even the current Automatic Updater will probably let you disable minor core updates.

            2. Decisions, not options principle How should a user decide what is the best and/or safest option? Displaying this as an option says there is a risk of some kind to let it stay on. WordPress would have to express a warning not to disable this, so then, why is it there?

            3. Introducing an option defeats the whole point of this enhancement. The enhancement was not just to add a new option, but to automatically do minor updates, since they are most security related.

            If, and when, WordPress enables Core Major as an automatic update, such option can be discussed again. Core Major may introduce new features than can alter plugin or theme functionality, so this may not be desired.

            But my idea, if and when Core Major is offered, and the next major is in RC, WordPress will ask the user if he is ready to upgrade automatically when released? (Y/N). This answer will be valid for one major release at time.

            If and when WordPress is offering automatic updates to theme and plugins, this could be as an option for each plugin or theme, eanbled by the plugin/theme author.

            For now, Core Minor is the target, without an UI option to turn it off.

            • RicaNeaga 8:03 pm on September 24, 2013 Permalink

              Ok, now I understand. Thank you for the explanation. :)

    • Simon Wheatley 8:28 am on September 24, 2013 Permalink | Log in to Reply

      I hope you at least considered using `define( ‘UPDATE_ALL_THE_THINGS’, true );`? :)

      • Dion Hulse 8:37 am on September 24, 2013 Permalink | Log in to Reply

        During initial patches, the Cron callback actually was wp_auto_upgrader_upgrade_all_the_things :)

        Still considering a constant by that name to enable Plugin+Theme+Core Major release updates though :)

        • Knut Sparhell 8:44 am on September 24, 2013 Permalink | Log in to Reply

          Please don’t. Enabling updates other than Core Minor should remain plugin territory (filters) in 3.7, even if core is able to perform the actual updates.

          • Dion Hulse 9:06 am on September 24, 2013 Permalink | Log in to Reply

            Curiously, Why do you see a Constant as being worse, than a user installing a plugin or using a filter?
            A plugin could simply define the constant, which would effectively be the same thing.

            Honestly though, we’re trying to avoid constants like this, instead relying upon filters, so Update-it-all is better suited to a plugin at this point.

            • Knut Sparhell 9:14 am on September 24, 2013 Permalink

              Mostly because, as you say, it’s better to let a plugin add filters than constants.

              And a constant makes it tempting for more (end) users to alter their wp-config.php to add yet another constant, when what they would need is a UI so they can see what extras are enabled.

              Constants in wp-config.php, if any, should be a thing for developers.

            • Knut Sparhell 9:21 am on September 24, 2013 Permalink

              Last sentence of my previous comment should be:

              Constants in wp-config.php, if any, should be a thing for developers having to restrict things for the site (but restrictions should also go into mu-plugins, when possible).

    • Knut Sparhell 9:48 am on September 24, 2013 Permalink | Log in to Reply

      This implementation looks to be even better than I hoped for. This is great! WordPress may proudly announce this new enhancement (not feature) for 3.7. From now on, when a serious vulnerability is discovered, WordPress may patch millions of sites in a few hours, making WordPress a far more robust platform and a real “set-it-an-forget-it” platform. This is the way WordPress is actually used by millions, while WordPress, until 3.7, haven’t really supported this approach and still remaining a safe platform.

      WordPress used to come with a warning, you MUST check for updates, but this is widely ignored. May site owners don’t visit their admin area (log in) for many months, as they may be satisfied with quite static “home page” type of site. And if they go into admin, they don’t dare to change anything if they are not completely sure that there is no side effect. So they leave without updating, just to be sure they didn’t do anything wrong, anything at all. Their site “works”, and that’s all they care about for now, not knowing their site may be vulnerable to attacks.

      From 3.7 there will also be possible to update the previous major release, if I understand it correctly. (After 3.8 is released, sites still on 3.7 may receive critical updates, if the lead committers decides this should be done?)

      I just wonder, what is the priority when both WP_AUTO_UPDATE_CORE and AUTOMATIC_UPDATER_DISABLED are true? I guess AUTOMATIC_UPDATER_DISABLED will decide, correct?

      • Dion Hulse 10:09 am on September 24, 2013 Permalink | Log in to Reply

        From now on, when a serious vulnerability is discovered, WordPress may patch millions of sites in a few hours, making WordPress a far more robust platform and a real “set-it-an-forget-it” platform.

        That’s one of the hopes, We also have the ability to control when an auto-update is released, for example, 3.7.1 might be announced/released as normal, and the auto-update would roll out 12 hours later if there’s been no reported injuries from the update – Not that there are often dramatic issues with security releases, which is why we’re confident we can launch with that.

        From 3.7 there will also be possible to update the previous major release, if I understand it correctly. (After 3.8 is released, sites still on 3.7 may receive critical updates, if the lead committers decides this should be done?)

        Whenever possible, WordPress has attempted to keep the previous branch up to date.
        For example, when 3.6 was released, the 3.5 SVN branch was “up to date” security wise, There’s stuff in the 3.5 branch that was never released as a 3.5.3.
        We could’ve released it the same day as we released 3.6, but there was no need to.. WordPress would just prompt users to update to 3.6 completely skipping over it. Many people who run large WordPress networks are aware of that and will pull in the branch updates while they continue to test the next major release.
        Come 3.8 though, as you realise, that can change, we can continue to patch 3.7.x and have users benefit from it. There’d probably be a cut off for back ports of security updates (ie. when 3.9 is released, 3.7 would stop getting security updates or something like that) but that isn’t something that’s been discussed yet.

        I just wonder, what is the priority when both WP_AUTO_UPDATE_CORE and AUTOMATIC_UPDATER_DISABLED are true?

        You’re right, the Disabled status will prevail, In the case of the Disabled constants, as soon as it’s hit, it stops even considering doing something, it’s a big red sign that says “Don’t do anything” – It’s really a kill switch.
        WP_AUTO_UPDATE_CORE (along with the filters which act upon it) is really just a preference if the upgrader isn’t disabled

        • Ian Dunn 4:14 pm on September 24, 2013 Permalink | Log in to Reply

          We also have the ability to control when an auto-update is released, for example, 3.7.1 might be announced/released as normal, and the auto-update would roll out 12 hours later if there’s been no reported injuries from the update

          …or maybe 12 hours earlier? That’d give us a little jump on anyone looking to exploit the vulnerability between the time it’s announced and the time the auto-update happens. Having a 12 hour window where a vulnerability is known-but-not-patched makes me uncomfortable, and lately I’ve been patching my installs within ~60 minutes of the new tag hitting the repo.

          Obviously attackers could setup a script to e-mail/SMS themselves when the SVN repo gets a new tag, but not all of them will, so it might help a little.

          • Dion Hulse 3:29 am on September 25, 2013 Permalink | Log in to Reply

            A 12-hour window would still be better than the several days/weeks that many people don’t update their installs at present.

            The timeframe was simply a example, there’d be no reason it couldn’t be made available at the same time as an official release if the core developers were confident in it.

        • Milan Dinić 9:29 pm on September 25, 2013 Permalink | Log in to Reply

          From now on, when a serious vulnerability is discovered, WordPress may patch millions of sites in a few hours, making WordPress a far more robust platform and a real “set-it-an-forget-it” platform.

          But will .org servers survive this? :)

    • Marcus 10:03 am on September 24, 2013 Permalink | Log in to Reply

      Very nice feature, great work Dion!

      There’s so many ‘static’ sites out there that get created and forgotten (I actually stumbled across a 3.1 site only yesterday!), this is perfect for those situations.

      Whilst the idea of doing this to business-critical sites somewhat makes me feel uneasy (mostly due to the fact that unecessary problems like plugin/theme jQuery incompatibilities with newer library updates), this’ll make the web a slightly safer place overall!

      • Dion Hulse 10:23 am on September 24, 2013 Permalink | Log in to Reply

        mostly due to the fact that unecessary problems like plugin/theme jQuery incompatibilities with newer library updates

        The good news is, such libraries would rarely be updated in a point release, It would only be if there was a particularly bad cross-site-scripting vulnerability or similar in the Javascript library which would cause it to be done – and even then, we’d not update to the latest version of the library, we’d simply update to a compatible security release (ie. 1.7.0 to 1.7.1).
        WordPress’s backwards-compatibility mantra also means there’s very rarely a break in compatibility, and if there is, it’ll be in a major release with a LOT of thought put in to it, and every possible alternative considered.

        • Knut Sparhell 1:01 pm on September 24, 2013 Permalink | Log in to Reply

          This not just good news, is part of the foundation of WordPress release policy: Point releases should only fix what’s needs to be fixed this way, that is security and regression. No stuffing in all the latest and greatest of external libraries, even how well tested. Minimal to no risk of breaking compatibility with whatever. Everything that does not have the purpose of making the branch more stable will have to wait to the next main release. This has always been the policy, as far back as I know.

          Even core hacks will probably survive, as the updates are incremental on file basis. Right?

          I hope the sceptics, the “no-automatic-updates” people, reads and understands this policy, and the main reasoning behind this enhancement. And then, if still sceptic, just see how easy they can avoid the whole thing by a introducing some constant, or, even better, installing a simple plugin.

    • Andrew Nacin 1:59 pm on September 24, 2013 Permalink | Log in to Reply

      Just adding something here: It will be against the policy of the plugin and theme directories for a plugin or theme to forcibly update themselves using the filters outlined here.

      • Knut Sparhell 2:28 pm on September 24, 2013 Permalink | Log in to Reply

        Seriously?

        So “Automatic Updater” will not comply with the policy? It auto updates itself. Will it be ok to auto update other themes or plugins, except itself? Can’t believe this.

        • Gary Pendergast 3:23 pm on September 24, 2013 Permalink | Log in to Reply

          It doesn’t specifically update itself, and it doesn’t force the update – it only updates itself when you enable updates for all plugins.

          I’ll be releasing an update soon that uses the core automatic upgrade routines, so it will quite literally be a wp-admin checkbox for the core functionality.

        • Ipstenu (Mika Epstein) 3:44 pm on September 24, 2013 Permalink | Log in to Reply

          No, the plugin is complying with our policy. It’s automating the update process for everyone, not ‘just’ itself. I know it sounds like hair-splitting, but this is clearly not ‘a plugin that only updates itself’ and instead is ‘a plugin that automates updates.’

          We’ve had ’em before, like the old WP plugin that would let you update WP inside WP (before that was in core), and they’ve always been allowed :) What isn’t would be if, say, Akismet automatically updated itself, and ONLY itself, when it had a new version.

          • Knut Sparhell 11:43 pm on September 24, 2013 Permalink | Log in to Reply

            Thanks for the clarification. I still think this rule is silly, though. I can see the need for rules that stops plugins from silently and forcefully take away some control the admin expects to have. But a plugin, that in its description says it will update itself, I would consider creative, whatever method used. Anyway, this “aside” discussion should probably be taken elsewhere.

    • Ipstenu (Mika Epstein) 3:46 pm on September 24, 2013 Permalink | Log in to Reply

      If the install uses FTP for updates (and prompts for credentials), automatic updates are disabled

      My install uses FTP for updates, but I have an FTP userID and password in my wp-config. So am I right in assuming this will work as expected and update me?

    • George Stephanis 4:38 pm on September 24, 2013 Permalink | Log in to Reply

      Love it.

      I personally won’t be using it, but for folks that it’d be useful for:

      https://github.com/georgestephanis/update-control

      It adds in tickboxes to the Settings > General for folks that need to be able to specify them manually through the UI.

      It’s already submitted for consideration on the plugin repo, it’s open to pull requests or changes wherever.

    • Sebastien 6:00 pm on September 24, 2013 Permalink | Log in to Reply

      This is an interesting feature. I will add this to the custom config setup in the next update for my WordPress Online Installer, WPSetup.

    • Mike Schinkel 6:11 pm on September 24, 2013 Permalink | Log in to Reply

      +1 for disabling updates when using SVN and Git.
      -1 for omitting the same check for Hg/Mercurial.

    • aronwp 4:11 pm on September 26, 2013 Permalink | Log in to Reply

      Ok, I was all for the automattic core upgrades after finding out it would not be major WordPress releases since people say that minor releases don’t break anything. Yesterday I upgraded a site to 3.6.1 from 3.6 and the site broke. (i had a backup so no big deal) but if this would have been an automattic update on a production environment the client would of been real mad. (this guy is not a happy camper) The site broke due to a plugin that worked fine on 3.6 but not on 3.6.1. It’s a woocommerce gravity forms product addon extension and here is the change log.

      “2013.09.12 – version 2.4.6
      * Fix: Remove wp_get_referer() in constructor for compatibility with WordPress 3.6.1 load order. ”

      This proves that anyone saying that a minor release cant break a website is dead wrong. Don’t get me wrong. I would love automattic upgrades but it’s not ready for mainstream yet. At least not that I can see.

      Aron

    • Ryan Hellyer 8:59 pm on September 26, 2013 Permalink | Log in to Reply

      This is a truly awesome addition to WordPress. Thanks to all of those who assisted with hammering out the plan and implementing it.

    • kevinjohngallagher 1:42 am on September 27, 2013 Permalink | Log in to Reply

      Friends,
      Shockingly I have an issue, but I think we can clear it up.

      As of [25598] WordPress 3.7+ installs will begin updating themselves without the need of user input every time a new security release has been released

      Although not a fan of automatic updating, I can understand the desire to implement it (the horse has bolted, so I’m not complaining). My challenge is the definition of “SECURITY RELEASE”. That’s not the same as x.1 release.

      In fact, every x.1 and x.2 release WordPress has had since 2.6 has included more than security fixes (bug fixes, functionality, small things that have been worked on, and presentation changes). If we limit this updating to SECURITY releases, then I’ll crawl back into my cave – but that is not something we’ve done so far.

      3.6.1, for example, had 22 code changes, of which 4 of them were presentation changes. Don’t get me wrong, bug fixes are great, but fixing a presentation bug for TinyMCE in iOS5 only… not security!!
      (https://core.trac.wordpress.org/changeset/25187)

      To stress, I think the code developed here is incredible, and it’s an awesome step forward. But I feel that the processes behind it are taking a very very huge leap without notice or in-depth edge-case planning.

      • Have we solved the process problem before the coding one?
      • Are we tagging security releases AND updates as separate minor releases?
      • Are we prepared to not release bugs we’ve fixed until the next major version?

      I’ve looked for the answers to these questions, and I can’t find them.

    • BC 7:56 am on October 8, 2013 Permalink | Log in to Reply

      Personally I think this is a bad idea and should be switched off by default – sure have a button in the admin panel that lets people choose – but don’t take this responsibility without being sure what it means.

      Why? Mostly trust. I don’t trust you to stop at only pushing security updates. I definitely don’t trust you not to break my sites with an upgrade. You will break it eventually (as you have each time for a subset of sites) and I want to be three when it happens. Finally I absolutely do not trust that you are more clever than a world full of evil hackers who are surely rubbing their hands with glee at the prospect of being able to automatically push their trash to millions of websites in a few hours after just one hack.

      This is the widest reaching change WP has ever made IMO and you are taking a big reputational risk that it will work first time all the time. You are removing choice and responsibility from admins and taking that yourself. I predict headline-grabbing failure at some point and lawsuits in your future. That bit about taking backups before upgrading you always tell people in the upgrade notes, for example, how are you doing that? When it doesn’t work how will you put it back as it was?

      As for auto-updating themes and plugins; that way madness lies. Madness with pitchforks and burning.

      I will add the constants to switch this off before I even upgrade to 3.7 and it will forever stay that way.

    • Mark Rowatt Anderson 9:21 am on October 11, 2013 Permalink | Log in to Reply

      Is ‘auto_upgrade_ignore_checkout_status’ the right filter for ignoring version control? I couldn’t get it to work for me, but using ‘auto_upgrade_is_vcs_checkout’ instead (and setting it to FALSE), does seem to work.

    • esmi 4:32 pm on October 11, 2013 Permalink | Log in to Reply

      Your WordPress install also needs to be able to contact WordPress.org over HTTPS connections, so your PHP install also needs OpenSSL installed and working
      What if cUrl isn’t enabled? I see maybe 1 or 2 of these a week on the support forums. Yesterday’s example was a host who had removed cUrl “for security reasons”!

      • Andrew Nacin 4:34 pm on October 11, 2013 Permalink | Log in to Reply

        WordPress technically works without cURL. In 3.7, the two remaining transports (streams and fsockopen) are combined into a single transport that, yes, supports SSL connections (assuming OpenSSL).

    • Lester Chan 12:32 am on October 16, 2013 Permalink | Log in to Reply

      “If the install is running as a SVN or GIT checkout, automatic updates are disabled”

      Does it check for .git and .svn folders to determine that?

      • Dion Hulse 3:42 pm on October 16, 2013 Permalink | Log in to Reply

        Yes, It looks for .svn, .git, .hg, and .bzr folders in ABSPATH, and every directory above that up to / (So if /home/user is a GIT Checkout, it’ll still detect /home/user/public_html/wordpress/ as being under a VCS checkout)

    • Remkus de Vries 8:49 am on October 16, 2013 Permalink | Log in to Reply

      Is there a way to filter the email address the notifications are being sent to?

    • Md Mahmudur Rahman 11:44 pm on October 24, 2013 Permalink | Log in to Reply

      I am using DeployHQ to deploy code to staging/production server and DeployHQ is connected with GitHub. So in this case this is not direct GIT checkout in the server. So I guess I have to add define( ‘AUTOMATIC_UPDATER_DISABLED’, true ); to the wp-config.php file. Right?

      • Alex Mills (Viper007Bond) 11:51 pm on October 24, 2013 Permalink | Log in to Reply

        Based on your environment, it sounds like setting DISALLOW_FILE_MODS would make more sense.

        It’ll also disable things like plugin and theme editing since you have that all under revision control.

    • Curt44319 4:02 pm on October 25, 2013 Permalink | Log in to Reply

      Auto-update without an opt-in is really, REALLY bad idea !
      Here is my post on another blog…

      I’ve been a ( paranoid ) systems administrator for some decades now, and one thing I’ve learned ( Micro$oft taught me very well ) is to NEVER, ever, under ANY circumstances, EVER enable auto-update of anything !
      Run it in a sandbox test environment first, to make sure someone’s idea of an “improvement” doesn’t fatally break something you depend on.
      I’ll be adding that line for now, but I am SO with Ann-Marie above.
      A plug-in autoupdate disabler patch right now, and a configurable option in the core ASAP if not sooner.

      and….

      And, I’ve just discovered this update DID break a depended on function in .htaccess, by completely replacing my finely tuned config without making a backup.
      Good thing I’d learned this long ago, and make my own backups as *I* see fit.

      • Ipstenu (Mika Epstein) 5:28 pm on October 25, 2013 Permalink | Log in to Reply

        Curt – remember these are only auto-updating MINOR releases. There will not be any major function changes in these. Please don’t compare your 3.6.1 -> 3.7 upgrade to this, but more your 3.6 to 3.6.1 :)

    • dfumagalli 2:39 am on October 27, 2013 Permalink | Log in to Reply

      There are HUGELY popular plug ins like qTranslate that self-disable and often stop working after minor upgrades.
      What are we going to do when some million websites go down in one hour?
      I have those plug ins on some mission critical websites, can’t afford joking around with fancy updates that break everything.
      I have some custom commercial super-complex plug ins that take days to get updated and then I have to painfully go through W3 Total Cache and change the CSS and Javascript order else the pages stop working.

      This is not Microsoft Windows, where unattended updates mostly interest a product made by one company, plug in makers are of all sorts of availability and skills, it’s a jump in the unknown to just let WP self update, even for minors.

      Definitely going to have to use the AUTOMATIC_UPDATER_DISABLED feature.

      • Andrew Nacin 3:54 pm on October 27, 2013 Permalink | Log in to Reply

        We’re talking about security releases, not omnibus or feature releases. We wouldn’t have implemented this if we were completely confident in the ability to release an update that doesn’t a site, even one loaded with the heaviest or worst plugins.

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel
Skip to toolbar