Make WordPress Core

Tagged: updates Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Nacin 12:39 am on January 24, 2014 Permalink
    Tags: , updates   

    3.8.1 auto update rollout 

    I’ll be using this thread to track the rollout of automatic background updates for 3.8.1, released earlier.

    The WP.org API is now sending update instructions to about 1 in every 128 sites. This is for all locales (not just English). 3.8.1 was released about four hours ago and I’d like to have the rollout complete in the next six hours or so. Sites check WP.org every 12 hours, but this timetable means all sites should be updating within one day of the initial release.

    So, why a slow rollout? Well, we’re monitoring a number of things that would cause us to put a pause on auto-updates, such as whether there were any critical issues in 3.8.1, whether update failure rates are higher than usual, how WP.org is handling the load, etc. The rollout is happening much faster this time than last time (3.7.1), and yes, the goal will be to eventually push out auto-update instructions immediately.

    So far, we’ve seen a 100% success rate for about a thousand auto-updates to 3.8.1, and north of 99% for one-click updates. (A reminder: a failure only means the site couldn’t update, not that it broke.) I’ll comment to this thread with more numbers as the rollout continues.

    • Andrew Nacin 12:45 am on January 24, 2014 Permalink

      In case you’re curious as to how this 1-in-128 is calculated, we take the first three characters of the md5 of the site’s URL and convert it to base 10. md5 is hexadecimal (base 16), so the three characters mean 4096 possibilities. It’s now serving sites where this base 10 number is 0 to 31.

      Just randomly serving an instruction every 128 requests wouldn’t work. We do it this way to ensure a site receives a consistent response with repeated API calls.

    • Jeff Rose 12:46 am on January 24, 2014 Permalink

      I’ll cop to being one of those one-button failures. My Digital Ocean test install had bad permissions. Not WordPress’s fault.

      • Andrew Nacin 12:50 am on January 24, 2014 Permalink

        What’s cool is we are actually able to break it down by error code. Bad permissions is what we’d consider a non-critical failure. The only time a “critical” failure occurs is if WordPress started to copy files over, but couldn’t verify we copied them all successfully. It’s still probable everything is fine with the site, and quite possible the update completed anyway.

        If an error occurs at any point before we start to copy files (such as a permissions error, which is a pre-flight check now), WordPress simply declines to continue. The vast majority of the less than 1% of errors we’re seeing from one-click updates are these kinds of errors.

    • Ipstenu (Mika Epstein) 12:47 am on January 24, 2014 Permalink

      Mine had a bad timing for an auto-update (yes, auto update WHILE I’m messing with files, that’s smart 😉 ). Stopped messing with files. It re-ran later and worked.

    • Andrew Nacin 12:59 am on January 24, 2014 Permalink

      Bumped to one out of every 64 sites.

    • Andrew Nacin 2:36 am on January 24, 2014 Permalink

      Now at one in every two sites. Will be holding steady here for possibly a few hours.

    • Andrew Nacin 4:11 am on January 24, 2014 Permalink

      Things are looking great, so all sites are now receiving auto-update instructions. The rollout is complete. We’ve seen about 100,000 successful updates in the last few hours.

    • Andrew Nacin 8:11 am on January 24, 2014 Permalink

      We briefly dialed it back to about 75% of sites after seeing hundreds of updates a second from installs set to UTC. We’ll bump it back up soon.

    • marvila 10:24 am on January 24, 2014 Permalink

      One quick doubt. I have a monitor on my system that alerts me whenever a file is changed on wordpress and, of course, it started to show me lots of file changes.

      Is there a place to see whether the auto-update is still happening? Just to be sure the alerts are really for the auto-update (although everything seems to indicate so).


      • Andrew Nacin 10:10 pm on January 24, 2014 Permalink

        Once you get a success email, the update is complete.

    • Knut Sparhell 11:39 am on January 24, 2014 Permalink

      All but one of the 35 sites I manage are localized (nb_NO), and they all have the “Advanced Automatic Updates” plugin with at least minor updates turned ON (most have ALL options ON). Some sites now has been background updated to 3.8.1 (no available updates indicated), but some has been updated to 3.8.1, but still waits for 3.8.1-nb_NO (says such update is available in the admin).

      May I expect all sites to update to 3.8.1-nb_NO, or do I have to “update” from 3.8.1 to 3.8.1-nb_NO by clicking the Update button on each site? For 3.7 to 3.7.1 no localized sites was fully updated and I had to do the last part, to nb_NO, myself.

      BTW: Tomorrow is WordCamp Norway!

      • Andrew Nacin 10:10 pm on January 24, 2014 Permalink

        If the site is running the 3.8 English package, it’ll update to 3.8.1 in English, even if the locale is set to nb_NO. It requires A) for an nb_NO package to exist, and B) for your version.php file to have $wp_locale_package = ‘nb_NO’, for it to update to the Norwegian package. I hope to make this better in the future.

        Have fun at WordCamp Norway. :-)

    • driveroll 12:53 pm on January 24, 2014 Permalink

      I’ve noticed these auto-updates on several of my sites, this is the first time it happens like that, automatically. I usually would prefer to update wordpress manually to take care of any possible conflicts with themes or plugins that aren’t ready for the update… I actually haven’t checked if any of these actually occurred on some of those sites. Is there a way for the auto-updates to notice if the site breaks for incompatibility reasons? Is there a way to choose not to run the auto-updates?


    • Gary Jones 2:50 pm on January 24, 2014 Permalink

      I had an interesting issue, which I can only put down to the 3.8.1 auto-update, as I’ve not edited code or content on my site for a few days.

      Others said that my site had lost its style. When I cleared my cache, yes, the style sheet link reference was broken:


      That’s the child theme name missing, and the version has reverted to the parent theme (Genesis Framework).

      I cleared the Varnish Static, Varnish Dynamic and Memcache caches in SiteGround User Area, and it’s all back up fine.

      My other sites on the same SG account, with different WP installs, all running child themes of Genesis 2.0.2, all look to have gone through perfectly fine. The affected site *only* has Genesis and the child theme installed (no Twenty* themes), but then that’s the same for the other installs as well.

      I can’t explain it.

      • Gary Jones 2:53 pm on January 24, 2014 Permalink

        The full link was:

        The ID there indicates that Genesis thought the child theme was still active (as it should have been), but somehow, the name and version number couldn’t be retrieved from it (file read issue?)

      • Ipstenu (Mika Epstein) 5:36 pm on January 24, 2014 Permalink

        Is the child theme still installed on the site?

        The upgrade should NOT delete any theme files. Actually … it can’t delete theme files, unless you named the child theme ‘twentyten’ or something.

        • Gary Jones 8:06 pm on January 24, 2014 Permalink

          The child theme was still installed, and apparently not touched (correct). A clearing of the host caches brought everything back up correctly.

      • Samuel Wood (Otto) 5:46 pm on January 24, 2014 Permalink

        Could be an issue with the files for the theme being temporarily unavailable. I’d check the filesystem on that particular server (or ask the host to do so). Also make sure you have an up-to-date backup of the site.

        There is a function called “validate_current_theme” that runs on the wp-admin/themes.php page. It checks that the relevant theme files exist. If they don’t, then it tries to switch the theme back to the default theme, which is currently twentyfourteen.

        In that switch process, if the default theme isn’t there either, then a quick read of the code seems to me that it could set the theme to a blank value, which would give the results you’re seeing.

        We’ve seen this in the past on some hosting setups where the filesystem was having intermittent failures. Users would say that it “randomly” switched back to the default theme. The theme validation check isn’t nearly as aggressive as it used to be, I think, but this is one possible way that it could happen.

        • Gary Jones 8:26 pm on January 24, 2014 Permalink

          That consequential explanation sounds viable.

          Lots of the files (in wp-includes, theme files, etc.) of the affected site are now 0755. As most files weren’t touched, that is likely from the initial install via Softaculous in cPanel, but it presumably rules out any file permissions issue.

          I’ve just checked the version.php of the other installs (the affected site was the root site, while others are add-on domains), and they still say 3.8, so they actually haven’t been touched.

          What’s more fun, is that version.php of the affected site says 3.8.1, yet I’m still getting an update notification in the WP admin.

          I’ve got one 3.8.0 install where the theme files are 0644 and folders are 0755, with twentyfourteen also present, another the same but without twentyfourteen present, and a third where the theme files are 0755. I’ll keep track and see if any break.

          I’ve commented out define( ‘WP_AUTO_UPDATE_CORE’, false ); which was added to wp-config.php by SiteGround Autoupdate, so that WordPress handles things itself.

          • Andrew Nacin 10:08 pm on January 24, 2014 Permalink

            validate_current_theme() won’t do anything unless you visit wp-admin/themes.php. This appears to be a hosting problem.

    • Gary Jones 2:54 pm on January 24, 2014 Permalink

      link rel=’stylesheet’ id=’child-theme-css’ href=’/wp-content/themes//style.css?ver=2.0.2′ type=’text/css’ media=’all’

    • KirkM 3:59 pm on January 24, 2014 Permalink

      I’m running 2 WordPress powered sites, the first being a rather ancient (going on 8 years on original install) but still viable personal blog and a newer (4 years) test site. The old personal blog updated automatically updated to 3.8.1 from 3.8 without a problem but I had to manually update the test site. The test site via the admin Update page. It did show that the 3.8.1 update was available though. Perhaps the auto-updates hadn’t gotten around to the test site yet or maybe the security plugin is keeping the auto-update from happening (see list of plugins for the test site). I have no way to be sure. No big deal though.

      Just for information purposes, the old personal blog site has the following plugins activated:

      All In One SEO Pack
      Artiss Transient Cleaner
      Better WP Security
      Clean Options
      Google Analytics for WordPress
      Lightbox Plus ColorBox
      P3 (Plugin Performance Profiler)
      Spam Free WordPress
      Subscribe to Comments Reloaded
      WP Revisions Control
      WP Robots Txt
      WP Super Cache

      And I’m running Weaver II Pro as a theme.

      The test site has the following plugins activated:

      Acunetix WP Security
      Clean Options
      Lightbox Plus ColorBox

      This site also runs the Weaver II Pro theme.

      So, no problems here really. No errors seen in any of the error logs for personal blog in regards to the auto-update. Considering how old the WordPress install is and what I’ve put the site through over the years, I’m glad to see the auto-update work so well. I do keep the site in good repair but still…great job to all!

    • Debbie Doglady 4:05 pm on January 24, 2014 Permalink

      I couldn’t do the one-click update. Got at “500 Internal Server Error”.

    • Xavier Borderie 4:41 pm on January 24, 2014 Permalink

      Automatic background updates is still not quite well-known among regular users: we (WPFR) received one e-mail from the owner of the (unknown to us) owner of a permanent makeup website running WP, about having received “quite a strange message”, with a copy of the “Congratulations on your auto update!” e-mail, and a question: “How come WordPress feels the right to update my site without my knowledge?”

      I told him everything about the feature, plugins to disable it and links to the Codex, and he answered with:

      Well let me thank you for showing to us that you can remotely control our site without our permission and without having been personally given access to the administration.

      Free software does not rhyme with abuse of rights.

      One final e-mail from me reassuring that no one ever touched his site, that it was all automatic and everything. No answer since then.

      But still. If one guy takes the time to complain about it, that means heaps of others are confused about it. It might be warranted to put more informational text in the e-mail sent on successful and failed updates.

      • Xavier Borderie 5:05 pm on January 24, 2014 Permalink

        Aside 1: his website is not even live yet, it’s apparently a test version for a forthcoming new version of their previously full-HTML site. I can understand the fury.

        Aside 2: a commenter on the FR announcement says he hopes his 3.6-using site (kept this way because it uses a 3.7+-incompatible plugin) will not be “brutally” updated to 3.8.1, and fears about update failures when the webmaster is unavailable for days (holidays).

        It’s all about education and good copy.

      • Ipstenu (Mika Epstein) 5:43 pm on January 24, 2014 Permalink

        Sadly this is an application of Zeno’s dichotomy paradox in action. We cannot ever alert 100% of the world.

        I would suggest you do a blast email (or a post on your site) explaining this to your customers. We did that at DreamHost and had a crazy small number of people who even blinked when they were upgraded. We told them it was coming beforehand, pointed out they COULD opt out, but we suggested they would not, and provided directions. The majority of people were fine with it (though I admit we already do upgrades for anyone who used our one-click upgrader), and the few who were not were glad to have the information on how to opt out.

        • Xavier Borderie 7:53 pm on January 24, 2014 Permalink

          Ah, but they’re not customers of ours :) I’m the fr_FR translator, and WPFR is the non-profit entity for that hosts the FR support forum and organizes the Paris WordCamp, so there’s no way we can e-mail everyone. That being said, we could tweet and write a blogpost about this beforehand, true, true… Thanks for the tip!

    • rossagrant 4:44 pm on January 24, 2014 Permalink

      Hey Andrew!

      Just a quick question.

      I woke up to an email this morning from my staging site saying that it had been updated to 3.8.1 automatically.

      My production site which is on the same server and is basically a duplicate of staging didn’t auto-update.

      I was already logged into my dashboard, hit refresh and then saw the manual update flyout. I hit it and it updated no problem.

      Another WP install on a sub-directory of my production site DID update automatically, so 2 out of the 3 sites on the same server basically.

      Is there anything I should look out for as to why the main production site didn’t auto-update?

      What are the triggers for the update? Did it matter that I was logged in as admin at the time?

      Would love to understand what triggers this.

      Thanks :)

    • ElleJG 7:09 pm on January 24, 2014 Permalink

      Holy komoly. Call me a control freak but I don’t like arbitrary updates. An auto update from 3.8 to 3.8.1 came as a complete surprise!

      Can someone confirm that this can only happen within versions? As in I won’t someday find that all of my sites have jumped from 3.8 to 3.9 without me deciding it was safe to do so? And should I decide that I would like to update all by my little self when I know it won’t break anything – how do I do that?

      Until every WP plugin developer is forced to update along with WP core – which can’t and won’t happen – I personally think auto updates are a bad idea. But hey, that’s just my opinion. :)

      Thanks guys. Would appreciate the info. I’m already trying to figure out a site problem today, and having this happen at the same time did not make me happy.

    • stevenhong 8:28 pm on January 24, 2014 Permalink

      Ok. My website broke based on this automatic update. I was on my site before lunch, and came back and when I hit my site again, it was in maintenance mode. Looked at the timestamp of the file and it was 8 minutes ago. Deleted .maintenance, and the site is broken.

      Fatal error: Class ‘WP_Query’ not found in /home/steveho/public_html/wp-settings.php on line 251

      is all I get, both on the front end, and when I try to log in via wp-admin.

      I thought it might be a conflict in plugins, so I went and removed all active plugins (via phpmyadmin) and it still doesn’t work.

      What did work was for me to copy all the 3.8.1 files onto my server, and follow the install instructions. Entire site is back and running with all the data intact.

    • keeperbay 9:44 pm on January 24, 2014 Permalink

      UPDATE. Have installed the “Disable Auto Update Patch” on 45 WordPress blogs today.
      Have 120 more to go.
      More orders rolling in.
      THANK YOU WP CORE!!! Once again you have kept me gainfully employed. I’ve never received so many orders in one day.

    • Andrew Nacin 10:03 pm on January 24, 2014 Permalink

      IF YOU NEED ASSISTANCE, USE THE SUPPORT FORUMS. I’m closing comments on this thread.


    • keeperbay 10:20 pm on January 24, 2014 Permalink

      Here are the problems:
      Problem #1. WP Core thinks that posting a link to Codex will help, but Most Bloggers Know Nothing About Code!

      Problem #2. Auto Updating assumes that all plugins are going to automatically work with the new version of WP – When has that EVER Happened?

      Problem #3. When Problem #2 occurs, those bloggers who fall into the category of Problem #1 are stuck paying to have their sites restored, fixed or rebuilt.

      • Andrew Nacin 10:51 pm on January 24, 2014 Permalink

        1. Bloggers shouldn’t need to rush to update their site to keep it secure and stable. If WordPress can take care of that, we should take care of that. They shouldn’t need to even go to the Codex for this. It “Just works.”

        2. We don’t break plugins in minor versions. Auto updates are for minor versions. We take a lot of precautionary steps. All we’re doing is fixing a few bugs and any security issues.

        3. I’ve yet to see a site break due to an auto update.

    • rossagrant 10:55 pm on January 24, 2014 Permalink

      @nacin used the update tester on production and all is well – thanks! :)

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

    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


      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


        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:


      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.


    • 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

      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!!

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

  • Andrew Nacin 7:46 pm on August 28, 2013 Permalink
    Tags: , updates   

    Core Updates in 3.7 

    One of the goals of WordPress 3.7 is to start automatically updating WordPress for minor releases. So, if you are running 3.7, you’ll be automatically updated to 3.7.1. @pento has worked on a plugin for this called Automatic Updater. It actually does a lot more than we need, like supporting nightly builds, SVN checkouts, and such. Based on some conversations with @dd32, here’s what we need to do for updates in 3.7:

    • Automatically update WordPress when we can. #22704
    • Verify the sanity of our download package, which includes package signing, SSL, etc., and only updating automatically if we are sure we are secure. #18577 #25007 #20074
    • Verify that files were copied over, to increase stability. #18201
    • Do anything else we can to increase stability, like #17301 #14049 #22881
    • Think about email notifications for updates to admin users (for when we can’t automatically update you). #10787
    • Think about allowing direct updates when we are group-writable, not just owner-writable. #10205

    If you are interested in any of these tickets, please jump on board!

    • joshua strebel 7:53 pm on August 28, 2013 Permalink | Log in to Reply

      Please consider an opt-out constant/mechanism simply for those of us that run multi-tenancy and manage the entire core package from the top down.

      • Andrew Nacin 10:22 pm on August 28, 2013 Permalink | Log in to Reply

        There will be a mechanism for this. We probably won’t start actually allowing sites to be auto-updated until a few hours or longer after a release, and then we’ll only do them in waves. It’s important to get all sites updated, but it’s also important to make sure it gets rolled out smoothly.

        There will be a mechanism (non-UI, so constant and/or filter) not only to turn it off, but to also turn it on for major releases. Please follow along development, we’d definitely like to hear feedback from hosting companies.

    • Unsal Korkmaz 8:01 pm on August 28, 2013 Permalink | Log in to Reply

      Automatically update sounds too risky for me :-S

    • nofearinc 8:26 pm on August 28, 2013 Permalink | Log in to Reply

      I’ve used Automatic Updater and would love to start on Tue or Wed tackling these together with whoever else is interested.

    • John Blackbourn (johnbillion) 8:32 pm on August 28, 2013 Permalink | Log in to Reply

      Discussion point: Should WordPress not auto-update if it detects a .git or .svn directory in the WordPress root directory?

      • Andrew Nacin 10:19 pm on August 28, 2013 Permalink | Log in to Reply

        WordPress won’t auto-update if it detects DISALLOW_FILE_MODS, for sure. Ideally, that should be set. We should also look for .git or .svn in the root, I can go for that.

        • Stefano Aglietti 9:23 am on September 2, 2013 Permalink | Log in to Reply

          Using DISALLOW_FILE_MODS that is used till now for other use (Disable Plugin and Theme Update and Installation) doesn’t sound a good idea. Cause auto update is a new feature introducing a new wp-config constant sound not so bad and something like ALLOW_WPCORE_AUTOUPDATE would be more clear to users. This constant could be inserted with value false to the wp-config-sample file

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

            DISALLOW_FILE_MODS is designed specifically to prevent any file modifications, This currently applies to the Theme/Plugin editor, AND theme/plugin/core updates, Automatic Updates will respect this constant.
            DISALLOW_FILE_EDIT disables the Theme/Plugin editor, and allows Updates to continue.

            The Core Auto-updater will have unique constants / filters related to it’s usage as well for finer-grained control.

    • Mark-k 5:57 am on August 29, 2013 Permalink | Log in to Reply

      what about backup before upgrade? maybe it is time to have some kind of backup functionality in core

      • chriscct7 4:59 pm on October 6, 2013 Permalink | Log in to Reply

        There’s too many variables with each site’s setup that core cannot possibly account for. This is why there are so many different types of backup plugins and services. Ideally moving forward, those plugins would hook into the autoupdater and backup automatically before an auto-update.

    • Dinesh Kesarwani 6:15 am on August 29, 2013 Permalink | Log in to Reply

      Automatic Updater sounds nice… but it needs few points to take care of, otherwise it may lead to broken site.

      • If new WP is released and it updates automatically. And, there is any plugin running, which is not compatible to currently released version.
      • If user is using any plugin/theme with his own (minor/major) customization. Does it is possible to take automatic backup of updating plugin/theme. So, user can rescue, if he lost something.

      It may be good idea in minor (plugin/theme) releases to update/replace the changed files only. It will reduce the data usage and speedy update.

      • Dion Hulse 1:39 pm on August 30, 2013 Permalink | Log in to Reply

        The plan is that Automated updates would not start immediately, they’ll be staggered so that early feedback can catch any significant incompatibilities and only be pushed out in the event that we’re sure there’ll be no breakage of users sites.

        It’s also worth noting, that as of WordPress 3.2, Security releases (ie. 3.2 -> 3.2.1) only update changed files, resulting in much faster & safer updates than major release (ie. 3.5 -> 3.6) updates.

    • alexphelps3 6:43 am on August 29, 2013 Permalink | Log in to Reply

      defining DISALLOW_FILE_MODS sounds like a good simple approach to me.

      I’d assume that most people that are running wordpress under a version control have already done this because if you don’t, any server local changes from an update will always conflict so you can’t push. I guess double checking isn’t a bad idea though.

    • Syed Balkhi 8:09 pm on August 29, 2013 Permalink | Log in to Reply

      Instead of opt-out for auto-upgrades… we should have opt-in for auto-updates. I think by default all new installs can have auto-updates turned on.

      But users should have a visual UI (i.e checkbox) to turn the auto-update off if wanted.

      Those with existing installs should be prompted via Pointers to opt-in to auto-upgrades.

      At least this way I’ll feel that I’m in control of the decisions that are made around my site rather than having someone else make the decision for me (even if it is for my own good).

      Just my 2 cents.

      • Ovidiu 9:43 pm on August 29, 2013 Permalink | Log in to Reply

        Totally agree. This needs to be an opt-in feature, not the way Facebook does, pushing all those pesky “innovations” down everyone’s throat.

        • chriscct7 5:01 pm on October 6, 2013 Permalink | Log in to Reply

          There’s a major fundamental difference between what Facebook does and WordPress core is proposing.

          Facebook pushes feature and ui changes.
          The autoupdates cover minor release points that historically are only bug fixes and security patches, not new features or changes to the UI.

    • Dane Morgan 10:35 pm on August 29, 2013 Permalink | Log in to Reply

      I agree that this should be an opt in to start. After a couple of iterations, letting people get used to it, then move to opt out.

    • Chuck Reynolds 10:55 pm on August 29, 2013 Permalink | Log in to Reply

      bring on the mother ship!

    • jeffr0 5:51 am on August 30, 2013 Permalink | Log in to Reply

      I don’t know how much this helps but back in 2011, I held a poll on WPTavern asking whether automatic upgrades should be opt-in. http://www.wptavern.com/should-automatic-upgrades-be-opt-in the majority of the votes said opt-in but having two years to think about it, I agree with Justin Tadlock when he mentions that if it’s not opt-out, then a ton of users will never know the option exists and thus defeats the purpose of having automatic updates to being with. Also, while initially against the idea somewhat, I’m fine with automatic upgrades for minor releases while still allowing me full control when upgrading to major versions.

    • Stefano Aglietti 10:01 am on August 30, 2013 Permalink | Log in to Reply

      You should consider also the I18N version, automatic update for maintenance release often are without strings changes but in the case, User should opt.in to have auto update and choose if auto update every new version or just the locale version when ready. This would mean for us translators more work and the need to make the locale release fast after the English one but should be ok. In case of no strings changes update can be done on English version immediately, this if there is a method to know the strings changes or not.

      • Dion Hulse 1:45 pm on August 30, 2013 Permalink | Log in to Reply

        Hopefully Language Packs will also land in 3.7 – #18200. That’ll allow us to somewhat decouple Languages from the WordPress version, allowing for Language files to be updated independently of the core build.
        For automated updates, that would mean that a minor update could update using the english package almost immediately, and if the language file needs to be updated (ie. one or two strings added/changed) then the translators could do that at any time and it’ll be picked up by the WordPress installs a few hours later.

    • Ben Huson 10:16 am on August 30, 2013 Permalink | Log in to Reply

      I’m happy with opt-out for minor upgrades which tend to be stable and usually just security fixes, and opt-in for major upgrades which may require testing with plugin configurations and hosting setup.

      That makes sense to me.

    • Ryan Hellyer 1:00 pm on August 30, 2013 Permalink | Log in to Reply

      Perhaps during the next update, a dialog box should pop open in the admin panel, where administrators get to choose between opting in or not. If it were written in an encouraging way, then presumably most people would opt-in anyway. This is a reasonably big change and is bound to upset some people, so opting-in seems like a smart idea to me.

    • Chris Lema 7:31 pm on August 30, 2013 Permalink | Log in to Reply

      This isn’t a question about whether to have it be opt-in or opt-out. This question is only tangentially related. But it’s a question that I’m hoping someone is thinking about.

      Since we’ve been talking about this being as easy as browser updates, I’ll relate it to my experience with Firefox.

      At one point I added several add-ons to Firefox. Then they asked me to update the core, which I did. Then, they discovered several add-ons didn’t work and deactivated them. Obviously my question is about plugins.

      But I’m not suggesting plugins do auto-updates. I’m instead asking about the impact to plugins when core changes. And most important, the validation checks, messaging, notifications, and dependent actions when plugins break because of core changes.

      So how do we treat a plugin that was dependent on a part of Core that we’ve now changed? Do we still do the upgrade? If so, do we deactivate the plugin? If not, do we notify the admin? Either way, do we notify the end user?

      • Andrew Nacin 7:46 pm on August 30, 2013 Permalink | Log in to Reply

        We’re only talking about minor releases, which are reserved for security issues and major regressions. If a plugin works in 3.7, it’ll work just fine in 3.7.1, 3.7.2, etc. We won’t start updating you to 3.8.1 if you’re running 3.7, only within your branch. (We may however release a 3.7.3 even after 3.8.1 is released and push that update out to 3.7.x sites — our future course for supporting older releases to be determined.)

        • Ipstenu (Mika Epstein) 8:37 pm on August 30, 2013 Permalink | Log in to Reply

          Replace ‘it’ll work just fine’ with ‘it should work just fine’ :)

          I will agree, though, very very very rarely does a minor upgrade break plugins, unless a plugin was actually broken all along and using other broken code to get the job done. Most plugin authors end up reporting those things back up stream, vs reverse engineer doing_it_wrong because they often can’t believe this was broken!

    • Ryan Hellyer 9:43 pm on August 30, 2013 Permalink | Log in to Reply

      I have a potential idea. Once this is up and operational (automatic minor updates), there will be situations in which the next major version has been released and is receiving incremental automatic updates, but many users will still be on the older version waiting for some dimwit to hit the automatic update button.

      Now imagine a scenario in which a major security flaw is found. Typically this would result in everyone being told to upgrade to the latest version. However in this scenario, many of those sites still sitting on the old version, will end up sitting there for a while in an insecure state. Perhaps if this scenario occurs, it would make sense to push a retrospective update in for the older version. I know this requires extra effort on the part of the core team, but chances are that if the patch worked in the new version, it would also work in the last few versions too. So once the patch for the latest version was launched, maybe the last version could also be patched.

      This breaks from the long time policy of telling everyone to update to the latest version, but since the update system is there, it seems silly not to just shunt an update out there if it can be done quickly and easily. It doesn’t even need to be an official policy, just a community service thing once the main release has been dealt with.

      Good idea? Bad idea?

      • Ipstenu (Mika Epstein) 11:17 pm on August 30, 2013 Permalink | Log in to Reply

        I seem to recall a 3.x release where a minor release for the old version was updated because the vuln came out the day after the major release. In that case, this makes perfect sense.

        That said, we want to limit ourselves to how much extra work do we want to introduce? I would say certainly no more than 30 days. Realisitcally I’d like to say 7-15 days from the release of the new major version of WP, we will no longer consider patching older versions, unless it’s something so big, we cannot even fathom it’s size in this moment.

      • Andrew Nacin 11:26 pm on August 30, 2013 Permalink | Log in to Reply

        Existing idea. :-) For some time, we’ve said we’ll keep two branches secure until trunk hits beta — so 3.5 and 3.6, until 3.7 beta 1. But, if 3.6.x is the current release, no one will bother to update to 3.5.x. So what ends up happening is we generally don’t tag that release, or even mark it as completed. But we will keep the branch updated for those following it. (We have packaged an older branch before, it just isn’t common. See also 3.0.6.)

        Automatic updates for minor releases certainly could change this a little. What I envision is if someone is running 3.7.1, and 3.8.1 comes out, we might update them to 3.7.2 — a release we previously might not have officially packaged, since core’s update UI would only show the latest release. It’s worth noting that the dashboard would continue to show only 3.8.1 is available — we’d just be willing to silently update them to 3.7.2 anyway.

        I don’t think it breaks the “everyone must update to the latest version” mantra. It just gives us one additional tool to make sure sites are secure if someone reports to us a particularly bad vulnerability.

    • Rodorm 9:40 pm on September 24, 2013 Permalink | Log in to Reply

      What if the WordPress server serving the updates is compromised and millions of blogs get an “extra” update and get compromised as well? That’s a HUGE risk which must be taken into account.

    • q120000 7:24 pm on October 4, 2013 Permalink | Log in to Reply

      First let me say, the WordPress team does a fantastic job. But why do I get the feeling that the auto-update issue sounds like Big Brother wanting to take care of me, or my web sites?

      Those who use WordPress that do not pay attention to core updates are just as likely to not pay attention to outdated and hacked plugins and themes. Responsible users will ensure they have updated software without the need to have it updated by someone else.

      Now I’m not the sharpest tack in the barrel, and I am not a coder, but the last thing I want to see when I log into one of my web sites that there was an update already performed. And this goes for my customer sites as well. I am a firm believer in Murphy’s Law, if something can go wrong, it will. I’d rather be notified of an update, and I can schedule when to do it. My choice would be during off hours just in case the site breaks I am there at the helm, so to speak, to take care of any issues.

      My preference is to “Opt In” rather than opt out.

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar