WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Tagged: 3.7 Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Nacin 5:24 pm on October 26, 2013 Permalink
    Tags: 3.7,   

    New plugin: Background Update Tester, from @dd32 and me. It does what it says… Most sites are able to apply updates in the background. This plugin checks your site for compatibility and explains any problems.

    After activating this plugin, visit the Dashboard → Update Tester screen. (If you are using multisite, visit Updates → Update Tester in the network admin.)

    Feedback and enhancement requests welcome. (I think we should add the ability to send a test email to see that your install can email you.) This is an early rough cut.

     
    • saulsolorzano 5:37 pm on October 26, 2013 Permalink | Log in to Reply

      Excellent! This is greatly appreciated. I’ll check it out. Cheers

    • George Stephanis 6:11 pm on October 26, 2013 Permalink | Log in to Reply

      needs moar textdomain

    • ScreenfeedFr 6:15 pm on October 26, 2013 Permalink | Log in to Reply

      “WARNING: Couldn#8217;t retrieve a list of the checksums for WordPress 3.7. This could mean that connections are failing to WordPress.org.”

      Han! :(

      url: https://api.wordpress.org/core/checksums/1.0/?version=3.7&locale=fr_FR
      response body: [body] => {“checksums”:false}

      • Andrew Nacin 6:46 pm on October 26, 2013 Permalink | Log in to Reply

        You’re likely OK. The plugin can’t tell the difference between get_core_checksums() failing, and simply not receiving any checksums. (Local builds don’t have them currently.) We can fix this by A) converting this warning to a simple ‘info’, and B) always query en_US for now (or avoid showing the warning when not using en_US).

        • Dion Hulse 11:53 pm on October 26, 2013 Permalink | Log in to Reply

          I’d lock it to using en_US, as it’s actually only using it as a 2-fold check to a) make sure communication works, and b) to know which files it needs to check are writable by PHP

    • Ipstenu (Mika Epstein) 9:08 pm on October 27, 2013 Permalink | Log in to Reply

      Wish list – Check if cron is working.

    • Fab1en 9:47 am on October 28, 2013 Permalink | Log in to Reply

      I tested this with a localhost install : 3 green PASS, but one Warning `Couldn#8217;t retrieve a list of the checksums for WordPress 3.7. This could mean that connections are failing to WordPress.org.`. Could it be because I do not have a ssl certificate to sign outgoing https requests ?

      • Dion Hulse 1:43 am on October 30, 2013 Permalink | Log in to Reply

        The Warning is only a warning, it’s not a failure.

        As of right this instant, I don’t think checksums are available for non-english installs, so that’s one possible reason for the notice. Running a Development version may also result in that message, and finally, the HTTP connection to the API timing out would also hit that message.

        So it’s not a sign that Background Updates won’t work, and it’s most likely not a issue, so don’t worry about it unless you can’t update / don’t receive an autoupdate in the next few days ( Background Updates are being rolled out to sites at a slow and steady pace ).

    • DreadLox 1:24 am on October 30, 2013 Permalink | Log in to Reply

      My sites do pass the tests and I know I can update directly without FTP. BUT, it keeps showing that 3.7.1 is available but it doesn’t seems to auto-update itself.

      No error message is showing up, only that 3.7.1 is available. I use a the french version

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

        Background updates occur at 7am/7pm Local time (whatever the timezone your blog is set to).

        Background updates are being rolled out at a slow pace to all sites, it may be a few hours before your site has been given the autoupdate offering, and then it’ll wait until the next 7am/7pm timeslot before it attempts the update.

        You’ll receive an email when the autoupdate completes (or if it encounters an error which prevents it from updating)

        • DreadLox 9:51 pm on October 30, 2013 Permalink | Log in to Reply

          24 hours passed, it is now 8am. Still no upgrade. Are localized versions of wordpress supported by that feature ?

    • DreadLox 9:40 pm on October 30, 2013 Permalink | Log in to Reply

      24 hours passed. None updated on its own (yet?), no email received.

      It concerns two websites, on two different hostings. Both had success reported by the Background Update Tester plugin. I’ll report back here, but it seems like the feature fails to me …

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

        Are you using non-english WP?

        • Naoko Takano 1:48 am on October 31, 2013 Permalink | Log in to Reply

          I have 2 installs of Japanese version with UTC+9 setting and neither of them has received background update.
          One of them has 3.7-ja (upgraded using Upgrade Now button), the other one is a test site that has been getting successful updates for beta & RC. I’ve turned off the Beta Tester plugin for this one.
          Both are tested for Background Update Tester plugin & on the same server.
          Hope that information helps.

      • Dion Hulse 1:56 am on October 31, 2013 Permalink | Log in to Reply

        Localised (non-english) installs are currently not receiving Background Updates.

        3.7.1 Background updates will be enabled for localised builds shortly, there’s just been some unexpected WordPress.org infrastructure work that needs to happen first.

        They’ll be enabled in the near future (next few days for sure) but in the meantime you can either update manually, or, if you’re not being affected by any of the bugs fixed in it (there’s no security fixes in this release) simply wait a few extra days for it to kick in.

        • Naoko Takano 3:21 am on October 31, 2013 Permalink | Log in to Reply

          Thanks for the update! I’ll let users know & share it on polyglots P2.

        • Chouby 8:29 am on October 31, 2013 Permalink | Log in to Reply

          Could this wordpress.org infrastructure issue explain that core languages packs are not updated? (I mean on an English install with manually added languages packs). According to my tests, it works for themes (tested with twenty twelve) but not for core.

          • Andrew Nacin 8:39 am on October 31, 2013 Permalink | Log in to Reply

            Auto updates require a lot of things on WP.org, while localized builds go through an entirely separate system. It’s taking some time to make sure everything is ready and proper. Will happen this week. Core language packs aren’t enabled yet (also part of the “ready and proper” piece), so that’s probably why they don’t work for you. :-)

            • Rootside 9:44 am on October 31, 2013 Permalink

              I have always installed the default version, but set the language to en_GB in wp-config.php. Does that mean the system is looking for a localised en_GB version?

            • Ipstenu (Mika Epstein) 1:36 pm on October 31, 2013 Permalink

              Rootside, yes.

            • Chouby 2:39 pm on October 31, 2013 Permalink

              Thanks for your clarification Andrew. I’ll be patient.

        • daveshine (David Decker) 10:00 am on November 1, 2013 Permalink | Log in to Reply

          Thanks for the info!
          I fully understand the reasons for it!

          However, what I cannot understand why this info wasn’t communicated upfront from the start of the 3.7.1 release. It currently confuses a lot of users why they don’t get their auto updates. For some of those users the confidence in auto-updates is already “damaged” which is really bad. We all work to convince users to rely on those important security/fix releases and auto background updates are really important. A little info update would have been really helpful.

          • Andrew Nacin 6:03 pm on November 1, 2013 Permalink | Log in to Reply

            From the announcement post: “we will start rolling out the all-new automatic background updates for WordPress 3.7.1 in the next few hours“. In all, it took us about 3 days to fully roll things out. Future releases will be quicker.

            I guess the tester plugin could have also made that clear, but the main way for them to have found that plugin would have been the very next sentence in the announcement post.

        • Rootside 12:29 pm on November 1, 2013 Permalink | Log in to Reply

          I’m with daveshine:

          What’s particularly confusing is that you do get the update notice (“3.7.1 available”), but the auto update doesn’t seem to click. Then the tester plugin reports that everything’s super great, and you immediately start wondering if your system is hooked up right.

          I understand that the delay to the 3.7.1 updates is a one-off, but I think the plugin would be a good place to tell people that the auto-updates run on a schedule and don’t necessarily kick in the second the update is released.

    • Muhammad Aftab 11:42 am on October 31, 2013 Permalink | Log in to Reply

      Nice…

    • kwdavids 12:21 am on November 2, 2013 Permalink | Log in to Reply

      So where does one go if the plug-in says everything passed, but the default-language sites don’t update?

  • Andrew Nacin 5:32 am on October 26, 2013 Permalink
    Tags: 3.7, 3.7.1   

    Tonight’s 3.7 nightly build is marked WordPress 3.7.1-beta1. Here’s the zip or use the Beta Tester plugin set to “point release nightlies.” It fixes #25689, #25690, #25700, #25705, and #25706. (See the report.) We’re also looking into a PCRE UTF-8 issue in #25709.

    #25700 is a particularly nasty bug that affects working with image captions in the visual editor. It was caused by a regression in Uglify.js. Please test. (It should also work with 3.7 with SCRIPT_DEBUG set, sans-patch.)

    As noted in my auto updates post, update fatigue is much less of an issue now, so our strategy for maintenance releases will surely undergo a shift. In this case, though, this one would have required a quick release no matter what. (We just might have felt a little bad cause of it.) Usually critical bugs are also hard to trigger, thus affecting few users. This one is easy to trigger.

    At this point, I’d expect 3.7.1 to drop over the weekend.

     
    • Abcmoteur 3:27 pm on October 27, 2013 Permalink | Log in to Reply

      Many thanks (#25700). :-)

    • niklasbr 9:22 pm on October 30, 2013 Permalink | Log in to Reply

      I don’t feel like I got a satisfactory answer here. I’d like to reassured though.

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

        I really don’t know HOW anyone can reassure you, if you don’t believe what’s being said right now. 3.7.1 dropped, and not a single site had a critical failure. Core is solid and fine. How your themes and plugins react may vary.

        • niklasbr 7:12 am on October 31, 2013 Permalink | Log in to Reply

          “not a single site had a critical failure”

          Is it possible to get some actual numbers rather than just words? WordPress core is pretty nice and stable, I agree with that. But none is running without any plugins installed and how do you know that there have not been a number of sudden incompatibility issues with them?

          • Andrew Nacin 8:05 am on October 31, 2013 Permalink | Log in to Reply

            Any plugin compatible with 3.7 will be compatible with 3.7.1. There are just two situations where that would not hold true:

            • We deliberately cause an incompatibility. The typical scenario is a security fix. Never would we do this in such a way that actually breaks sites. I think we spend longer evaluating security fixes for whether we broke anything else than whether we fixed the issue.
            • Or. we mess up. Starting with 3.7.1, we’ve stepped up our vigilance and testing (more unit tests, additional levels of review, stricter standards). Such a problem would occur even with manual updates, and would be detected quickly. This is also one of the reasons why we intend to delay the rollout of auto-updates by a few hours in most situations.

            I’ve been contributing for 4 years and have personally overseen something like two dozen minor releases that have contained many hundreds of fixes. I only need a few fingers to count up the number of times either of these situations have happened, and they’ve always been minor and/or extremely limited in impact.

            Beyond those situations, the only way a site is going to break during an auto-update is if the files were not properly updated. In the case of 3.7.1, any combination of files could fail to copy and the site would still work. It was designed explicitly with that in mind. (See the full diff here if you are curious.) It is hypothetically possible that a file is only partially copied over (as in, corrupted), but we catch that thanks to checksum comparisons, and re-try the copy. If at the end of an update we realize we only updated some files and couldn’t update others, we then roll the whole thing back, undoing any successful copies.

            The checks an install performs for auto updates are actually stricter than regular updates triggered by pushing a button, just to make sure we don’t break a site.

            We’ve performed more than 450,000 successful auto updates so far. The total number of situations where we’ve needed to roll back a site to 3.7 is 18. That’s 99.997%.

            • niklasbr 5:27 pm on October 31, 2013 Permalink

              I said it before, but it is worth repeating: I do trust you when you say that WordPress core will update fine in >99.99% of the cases.

              However, my experience with plugins from Gravity Forms, WP Super Cache and Jetpack have been less than stellar when it comes to updates. Unfortunately.

              I do not know if that 99.997% includes any data whether any plugins broke. Does it?

              Most plugins survive the update most of the time. That is certainly the truth as well. I do not doubt that.

              I accept that some things might break, it is part of my job overseeing i-dont-know-how-many-dozen WordPress installations for customers of mine. However, when stuff breaks automatically and none is there to oversee it the situation becomes critical.

              A very high success rate is super-sweet when one can have some oversight, it is however panic-inducing whenever it happens automatically. I hope you understand that.

              Would you offer some sort of hook for plugins so that they can self-test in the case of an update? Or perhaps a hook that allows a plugin to test other plugins prior to applying an update?

          • Ipstenu (Mika Epstein) 7:47 pm on October 31, 2013 Permalink | Log in to Reply

            However, my experience with plugins from Gravity Forms, WP Super Cache and Jetpack have been less than stellar when it comes to updates.

            Are you saying they break following major WP updates (3.5 to 3.6) or minor (3.5 to 3.5.1)?

            Keep in mind, we’re NOT talking about major WP releases, nor are we talking about the plugins themselves pushing a new version. We’re only talking about WordPress minor point releases.

            • niklasbr 7:56 pm on October 31, 2013 Permalink

              I’ve had plugins break at minor version updates (from memory I know that 3.6 to 3.6.1, 3.5 to 3.5.1, and 3.3.1 to 3.3.2 have caused plugins to not function properly).

              This was most certainly problems with the plugins and no fault of WordPress at all. But it still happened, and having it happen automatically when none is there to oversee or test it is what compounds these errors from annoyance to a real issue.

    • Chijo 6:47 pm on November 1, 2013 Permalink | Log in to Reply

      First, great job to the WP developers and all their hard work on the project. WP is a great application.

      I am however, in the same boat as others who are concerned about “something” breaking on a site after an auto update and a backup that we normally would have made just prior to manually updating, is not available. Additionally, I can see critical phone calls from clients asking us why their site has lost a certain plugin functionality and we are not immediately available to troubleshoot. Traditionally, we’ve saved WP or plugin updates to certain times of the day when we can make backups and troubleshoot any incompatibility issues immediately.

      Now, it seems that we won’t necessarily know about any issues until a client calls us up. This is not the responsible type of customer service that we’ve tried to provide over the years to our clients. We’ve supported the warnings on the WP update page (http://codex.wordpress.org/Updating_WordPress) to make backups prior to any updates and also recall a blurb at the bottom of the page reminding us that we can simply roll back a site using our backup if something were to break.

      ————————————
      “Before you get started, it’s a good idea to back up your website. This means if there are any issues you can easily restore your website. Complete instructions to make a backup can be found in the WordPress Backups section of the Codex.”

      “If you experience problems after the upgrade, you can always restore your backup and replace the files with ones from your previous version from the release archive.”
      ————————————

      So now it appears that we will have to rely on daily backups that may not include updates made to a site between the nightly back and the time of the auto update.

      I just saw this issue as I was researching why a client site of ours had errors on their Calendar. http://tri.be/support/forums/topic/missing-months-apparent-jquery-issue-after-most-recent-wordpress-upgrade/.

      As a professional attempting to provide the best possible customer service to our clients, I implore the WP developers to implement a “switch” somewhere in the Admin to disable auto updates that may be ON by default.

      Thank you very much.

    • acebravo 4:09 pm on December 14, 2013 Permalink | Log in to Reply

      Thanks,

      I’m sorry I’m not well versed in this stuff let alone PHP programming; all I know is that my site gave me update notification I believe 2 days ago to update to 3.8, I figured I will wait till the weekend and then click update…to my surprise, yesterday around noon time EST, I logged in to my dashboard and found that 3.8 was running..how did that happen? automatically? this is a major release here 3.7.1 to 3.8???

      I don’t mind minor updates to be auto, but major and core, I would like to decide when to do them…I need to backup, I need to choose the time..right in the middle of the day is not a good idea at all.

      Please advise!!!

      • acebravo 4:11 pm on December 14, 2013 Permalink | Log in to Reply

        Apologies I just realized that this should’ve been posted in The definitive guide to disabling auto updates in WordPress 3.7…I was there but in the middle of looking for answers…

      • Andrew Nacin 6:10 pm on December 14, 2013 Permalink | Log in to Reply

        This was very likely your hosting company (which is not a bad thing). It definitely wasn’t due to an instruction by WordPress.org; core will refuse to do an auto-update across major versions unless the filter (or constant) is used.

    • acebravo 8:26 pm on December 14, 2013 Permalink | Log in to Reply

      Thanks for the reply, I did ask them earlier before posting but they denied…typical

    • acebravo 11:58 am on December 16, 2013 Permalink | Log in to Reply

      I did not test this, but can an author update? or is it only the admin that gets the update option?

      Thanks,

  • Andrew Nacin 4:50 pm on October 25, 2013 Permalink
    Tags: 3.7,   

    The definitive guide to disabling auto updates in WordPress 3.7 

    There are a lot of ways to adjust automatic background updates. A number of constants and filters offer a range of control, from the fine-grained to the heavy-handed. I will readily admit there are a few compelling reasons to disable auto updates, including:

    • You manage your site using version control
    • You implement your own deployment mechanism (potentially to multiple servers)
    • You are a managed WordPress host and feel confident in pushing timely updates yourself

    I’d argue that “I don’t want them” is not a compelling reason for disabling updates. If you don’t keep your site up to date, you are making the web a less safe place for you and everyone who visits your website.

    Background updates are incredibly, incredibly safe. Sites already running WordPress 3.7 have attempted more than 110,000 updates without a single critical failure, thanks to a number of verification steps that have made updates that much more reliable. A background update for a minor or security release (which is all they are enabled for, by default) means downloading and copying over just a few files. We’ve gotten really good at that. We’ve also spent years honing our craft of shipping stable and targeted fixes in minor releases — we don’t indiscriminately backport bug fixes. They must be serious bugs, and fixes go through additional levels of review, including at least two lead developers. And, we have the ability to roll out an automatic update over a period of hours or days. For 3.7.1, we’ll likely see how a few hours of user-initiated updates go before telling about 1% of sites to update, then steadily increase that percentage.

    Automatic updates also support older branches. If the current version is 3.8.1, and we release a new 3.8.2 security release, we now have the option to release a 3.7.2 package with those fixes so 3.7 and 3.7.1 installs can automatically update to a secure version. (You’ll still be told to update to 3.8.2, of course.) Yes, automatic updates will definitely change how we approach maintenance releases and security fixes. We’d love the opportunity to keep lagging installs secure. I’d also expect more frequent maintenance releases for the current branch of WordPress, since update fatigue is much less of an issue now.

    Updates are also really fast. Installs take about 24 seconds to update on average, but that includes downloading and unzipping the package. A core update should put your site into maintenance mode for only a few seconds.

    What if you want automatic updates, but your site is telling you it is unable to apply these updates automatically? [Updated:] There is a new plugin, Background Update Tester, that will explain exactly why your site doesn’t support automatic background updates, and if necessary, what to ask your web host. This didn’t ship in core because it’s a pretty complicated flowchart and most options for recourse are complicated and technical. We think about 80 percent of installs support automatic updates. Most common reasons why they don’t work: your install’s file permissions require us to use FTP, and we don’t know your password; you have it disabled (or are using version control, see below); the WordPress cron (which also handles things like scheduled posts) doesn’t work on your server; or your install doesn’t allow for secure communication with WordPress.org. There are also situations (like inconsistent file permissions) where WordPress thinks it can do an update, but when it tries to, it finds out it can’t. (Your install will email you in that case.)

    It’s worth noting that the “automatic updater” controls more than just WordPress core. If the updater finds it can’t or shouldn’t update, it’ll still send site administrator an email. (Want to disable only that? It’s also covered in this post.) The automatic updater also supports themes and plugins on an opt-in basis. And by default, translations (for themes, plugins, and eventually core) are updated automatically. At some point in the future, the WordPress.org plugin security team will be able to suggest that installs automatically update malicious or dangerously insecure plugins. That’s a huge win for a safer web.

    It’s pretty clear that disabling the entire updater also disables some pretty nice features! Selectively disabling only what you want is going to be best. So, here’s the different ways to disable automatic background updates:

    1. Use version control.

    If WordPress detects a version control system, it recognizes you know what you are doing and avoids automatic updates of any kind. It looks for Subversion, Git, Mercurial, and Bazaar, and it looks everywhere.

    It works by searching two directories (ABSPATH and whatever you are updating, like WP_PLUGINS_DIR, or WP_LANG_DIR) for VCS directories (.svn, .git, .hg, .bz). And it looks a level up, too — and keeps looking until it reaches the root of the drive. So if you are running a single Subversion checkout at / or /var/www/ or /var/www/mysite.com/, the WordPress install at /var/www/mysite.com/public_html/wordpress/ will be blocked from receiving updates. Clearly, it errs on the site of caution.

    There is a filter, automatic_updates_is_vcs_checkout. If you’d like to use automatic updates anyway, you can just return false through that filter. The filter is also passed the directory it is searching in addition to ABSPATH, so if you wanted to update languages even though you were running a Subversion checkout, this would work:

    function update_languages_vcs( $checkout, $context ) {
    	if ( $context == WP_LANG_DIR )
    		return false;
    	return $checkout;
    }
    add_filter( 'automatic_updates_is_vcs_checkout', 'update_languages_vcs', 10, 2 );
    

    If WordPress can’t update due to version control, the admin email will still get notified of new minor releases.

    One technique that may interest some is to allow automatic updates even when using version control, with the intention of then checking in the changes once you get around to it. For the personal site of a busy developer, it’s an intriguing idea.

    2. Disallow all file changes, period.

    Most people are not going to want to use this one (honestly, please don’t), but if you are already doing your own deployments or are managing multiple servers, you might already be.

    The DISALLOW_FILE_MODS constant blocks any kind of filesystem changes, not just by background updates but by all users as well. So, gone are the file editors; the ability to update core, themes, or plugins; and the ability to install new themes or plugins. This is crazy stupid to use unless you know exactly what you are doing. I am only mentioning it because I wanted to make it clear that automatic updates is smart enough to avoid breaking any custom deployments.

    This will also block the update notifications sent via email for minor core releases.

    3. Disallow the entire automatic updater.

    The constant AUTOMATIC_UPDATER_DISABLED can be used to disable the automatic updater entirely. It’s like DISALLOW_FILE_MODS — no changes allowed at all — but it’s specific to the auto updater.

    Don’t use this to block only core updates! You’ll also be blocking a lot of other functionality. You won’t get translation updates (language packs) for core, themes, and plugins. You won’t receive update notifications sent via email to alert you of new WordPress releases. It also disables all opportunity for fine-grained control.

    There are very limited use cases for disabling the automatic updater but not disabling all file changes with DISALLOW_FILE_MODS. Just remember it disables everything, not just core updates, which are just one component.

    There’s also a filter by the same name, automatic_updater_disabled. (It overrides the constant.)

    4. Disable only core updates.

    The easiest way to manipulate core updates is with the WP_AUTO_UPDATE_CORE constant:

    # Disables all core updates:
    define( 'WP_AUTO_UPDATE_CORE', false );
    
    # Enables all core updates, including minor and major:
    define( 'WP_AUTO_UPDATE_CORE', true );
    
    # Enables core updates for minor releases (default):
    define( 'WP_AUTO_UPDATE_CORE', 'minor' );
    

    There are also some filters you can use for even finer control, which override the constant if used: allow_dev_auto_core_updates (like updating from 3.7-RC to 3.7-RC2), allow_minor_auto_core_updates (updating from 3.7 to 3.7.1), allow_major_auto_core_updates (3.7 to 3.8). Return true through these filters to allow such updates, false to disallow.

    5. Manipulate core, plugin, theme, and translation updates as they are prepared to be run.

    The previous configuration options are all-or-nothing. You may, however, want something more fine-grained. The auto_update_$type filter (auto_update_core, auto_update_plugin, auto_update_theme, auto_update_translation) is fired for specific updates, as they are ready to be updated. This filter is passed the actual update object that describes what WordPress is about to update. This means you can selectively enable individual plugins or themes to update, for example, or whitelist upcoming core updates.

    6. Manipulate whether notification emails are sent

    Emails are sent in three situations: a result email after a core auto update, a notification email when WordPress can’t update irself, and a debugging email when running a development version of WordPress (alpha/beta/RC).

    The result email comes in three forms:

    • A successful update. Nice!
    • An update that couldn’t occur. As in, WordPress tried to update, but failed early, like an inconsistent permissions error it was able to catch.
    • A critical failure, when the update failed in the middle of copying files.
    • (Note, we’ve yet to see a single critical failure in the wild. Yeah, it’s that reliable.)

      You can stop these emails from being sent by returning false via the auto_core_update_send_email filter:

      /* <a href='http://profiles.wordpress.org/param' class='mention'>@param</a> bool   $send        Whether to send the email. Default true.
       * <a href='http://profiles.wordpress.org/param' class='mention'>@param</a> string $type        The type of email to send.
       *                            Can be one of 'success', 'fail', 'critical'.
       * <a href='http://profiles.wordpress.org/param' class='mention'>@param</a> object $core_update The update offer that was attempted.
       * <a href='http://profiles.wordpress.org/param' class='mention'>@param</a> mixed  $result      The result for the core update. Can be WP_Error.
       */
      apply_filters( 'auto_core_update_send_email', true, $type, $core_update, $result );
      

      Next, the core notification email is controlled by the send_core_update_notification_email filter. By default, administrators are notified when the update offer received from WordPress.org sets a particular flag — of course, only if the install is unable to update. It’ll only email you once per new version, unless the admin email changes. Returning true means the install will always email you when there is a new update, even if the API has not yet instructed the install to do so. Returning false prevents the email from ever being sent.

      Finally, the debugging email is a complete log output of all auto updates performed — core, translations, plugins, and themes. It is as if you clicked update yourself and watched the text scroll by; it also includes additional error data if something went wrong. This email controlled by the automatic_updates_send_debug_email filter. Returning false will prevent this email from being sent when running a development install, while returning true will send this email to all versions, including when you’re on a stable release.

      ***

      In the end, please choose wisely. If you’re going to block core updates, use WP_AUTO_CORE_UPDATE.

      I’ve gotten this question a few times now: should hosts that offer WordPress update services be disabling self-updates? I have no qualms with hosts who plan to reliably provide their own updates in a timely manner to do updates on their own. Because they have full, unadulterated access to the server, they can do it much more effectively than WordPress can. They can also offer support services. It’s also much more awesome to have a hosting company on board, than to lean back and rest on WordPress’s laurels. Many hosting companies are also setting the bar high and paving the way forward by pushing out major releases after a few weeks of testing, which is fantastic. Of course, this means the host must act immediately and responsibly to push out maintenance and security releases. This is something most of them are already doing, even inside the first 12 hours. (That’s how often installs check WordPress.org to see if there is a pending update.) Honestly, I’m just really excited about how much the community is embracing all of this!

      So, if you’re a managed host that handles your own updates, consider using WP_AUTO_CORE_UPDATE versus completely disabling the entire automatic updater. (If you want to send your own emails, block the ones WordPress sends using the send_core_update_notification_email filter.) There’s a lot more to come here, and it would be a shame if users were cut off from its full potential.

      If you are a developer who wants to learn more, start with the WP_Automatic_Updater class in wp-admin/includes/class-wp-upgrader.php. Also check out @dd32‘s previous post.

     
    • Scott Kingsley Clark 4:58 pm on October 25, 2013 Permalink

      Sort of losing my “stuff” about this:

      “Automatic updates also support older branches. If the current version is 3.8.1, and we release a new 3.8.2 security release, we now have the option to release a 3.7.2 package with those fixes so 3.7 and 3.7.1 installs can automatically update to a secure version. (You’ll still be told to update to 3.8.2, of course.) Yes, automatic updates will definitely change how we approach maintenance releases and security fixes. We’d love the opportunity to keep lagging installs secure. I’d also expect more frequent maintenance releases for the current branch of WordPress, since update fatigue is much less of an issue now.”

      Just wow, that’s *amazing*!

    • Aaron D. Campbell 5:10 pm on October 25, 2013 Permalink

      On the flip-side of this, if you want to enable the awesomeness that is background updates for major releases as well, you can use http://wordpress.org/plugins/update-control/ to play with the various options or https://github.com/OpenRange/background-updates-for-major-releases for a no-options “activate and ignore” approach. I added the latter to all my family’s sites so I won’t have to keep upgrading them.

    • Nile Flores 7:24 pm on October 25, 2013 Permalink

      Thank you for sharing this. For me, I like to manage ALL of my updates personally. It’s not that I don’t update, but I don’t want to have what happened this morning even on a security update. I understand the ease of allowing this, but I just had a minor issue with updating with 3.7 this morning…and that hasn’t happened since 2.7 for me.

      I don’t care about 110,000 or whatever number or more, I just know what I have for my own website and what my own process is. I understand WordPress is trying to make it easier and love that, but I prefer to keep all control of my updating in my hands.

      Again, thank you for sharing this and Mika shared the Master List and the Codex page on this too this morning shortly after I had issues with my update.

      • Ipstenu (Mika Epstein) 7:39 pm on October 25, 2013 Permalink

        Keep in mind, auto-updats are for MINOR versions over. So don’t compare this process to 3.6.x to 3.7. Compare it to how your 3.6 to 3.6.1 upgrade went.

    • niklasbr 9:02 pm on October 25, 2013 Permalink

      If I choose to keep auto update active how can I be sure that updates won’t break compatibility with anything installed?

      • Andrew Nacin 10:25 pm on October 25, 2013 Permalink

        I would read the post. :-) We’re talking about security and maintenance releases, not major releases.

        We’ve also spent years honing our craft of shipping stable and targeted fixes in minor releases — we don’t indiscriminately backport bug fixes. They must be serious bugs, and fixes go through additional levels of review, including at least two lead developers. And, we have the ability to roll out an automatic update over a period of hours or days. For 3.7.1, we’ll likely see how a few hours of user-initiated updates go before telling about 1% of sites to update, then steadily increase that percentage.

        Very simply: Don’t be concerned. Minor releases don’t break things. We have your back.

        • niklasbr 7:31 am on October 26, 2013 Permalink

          I should have phrased my question differently:

          I simply don’t believe (from experience with 3.6.1 and 3.5.1 and 3.3.2 have all had trouble with plugins) you when you write that you won’t break anything. What assurances do I have that what you say is true and not just some words on a blog?

          • niklasbr 5:30 pm on October 26, 2013 Permalink

            Addendum: The reason I am asking is that I want to use automatic updates, but I don’t fully trust the WordPress code base enough, even tough I want to trust it.

    • IgniteWoo.com Team 9:30 pm on October 25, 2013 Permalink

      Extremely bad idea to not have a simple switch in the settings to turn off automatic updates. How many WP users can write PHP code to do it themselves? Not many. Geez even my high tech phone prompts me to install updates, which I can decline if I so choose ( I don’t have to write a single line of code either ) – e.g. my freedom of choice is hi-jacked by WP. WTH?

      • Andrew Nacin 4:06 am on October 26, 2013 Permalink

        WordPress has prompted users to install updates for years. I don’t know how many declined as much as didn’t pay attention or consider it a priority. Your phone buzzes in your pocket; it’s something you can choose right then to act on. If you don’t use your phone for a while, it’s probably not a big deal if you wait for an update. But running a site on the Internet carries some responsibility, and they don’t buzz in your pocket. (Out of sight, out of mind.) For the betterment of the web, we made a conscious decision to avoid a UI option. You’d be out of your mind to consciously avoid updating to fix a critical bug or security issue. We think the vast majority of users (many who don’t even know what PHP is) will celebrate this as a win in usability and security.

        We very strongly pride in our core philosophies, including designing for the majority, making WordPress work out of the box with little configuration or setup, choosing decisions instead of adding options, and striving for simplicity. (Incidentally, that last section needs updating to emphasize we’ve now made updates even simpler.)

        There are 27,000 plugins in the directory. Your freedom of choice is unscathed.

    • Andrew Nacin 10:48 pm on October 25, 2013 Permalink

      There was a question about minor versus security releases on WP Tavern. I answered it. My comment:

      In practice, minor releases are rare. The .1 release will always be needed to fix some bugs. Pretty much all others are security releases. Sometimes, the .1 also contains security fixes. A .2+ release is only going to happen for security reasons if there is a serious regression that somehow wasn’t discovered before the .1 release (which implies it probably wasn’t that serious).

      Generally, then: .1 is a minor release with serious bug fixes. .2 is a security release and/or a critical regression fix. If you’re on 3.7, you’re going to want a regression from 3.6 fixed on your site. There’s really no reason to decline either of those releases. No, there is no differentiating in terms of how we version them, and we don’t plan to do so.

      Finally: We have the ability to push out a minor release without having it auto-updated. We also have the ability to slowly roll out auto-update instructions. Essentially: We have a lot of tools at our disposal to ensure your site is getting exactly the fixes it needs. For more on this, read the definitive guide I wrote. I also talk about how this might mean more frequent minor releases, but that might just mean that .1 might be less of an omnibus release four to six weeks later, and is instead only a week or two later with a few important bug fixes.

    • Marcus 1:07 pm on October 26, 2013 Permalink

      I was under the impression that these auto-updates are exclusive to wordpress itself, not themes or plugins, but point 5 in your great writeup makes me want to ask for clarification:

      will plugins and themes also update themselves automatically in any way?

      • Trifon 4:53 pm on October 26, 2013 Permalink

        By default; no, it only updates Core.
        But it is possible to update themes and plugins with these options.

    • EMG 1:15 am on October 27, 2013 Permalink

      When there’s a security vulnerability and something malicious can happen (I remember way back when there was the problem with spammers and scammers hacking into certain WP versions and injecting in links to malware sites if not outright corrupting site accessibility), I personally don’t see how an automatic security fix would be unappreciated.

      So yes, after years of using WP from its 2.X days and seeing a variety of problems sneak in through security issues, I can see this as a win-win scenario.

      However, as an advanced WordPress user, I would hesitate to support anything more than this in the future and especially not without a way to opt in and opt out.

      I really admire that the WP team looks out for their userbase – including those who would really ultimately benefit from a more streamlined and simplified process and even desire such a thing.

      The simplification and streamlining of processes could be really helpful (like in the case I first mentioned above)… until it genuinely starts to impinge on the user experience and user choice in a negative way.

      Personally, though, I’m not that sort of user.

      After so many years of using and supporting WP, I am in the habit of always checking WP for news and updates for information and if there’s a new release, I read the information before diving in and though seldom do minor updates come with compatibility issues, it has happened before (and no, I never alter core files) and for this reason, I have always weighed my choices before making a decision and I dislike my ‘choice’ of making a decision being taken away from me… even if it was a choice I myself would have made on my own terms.

      I run a self-install on my own site; not on .com’s network.

      I am responsible for my own website, not WordPress.

      If a bug gets in, that’s my fault and the onus is on me.

      If I make a choice to not break some functionality immediately and wait to do a maintainance or security fix so I can make a backup first just to be sure, then that is my choice and if I get some kind of malicious code injected into my site in the meanwhile, so be it.

      Reading a readme and clicking an extra button or two isn’t going to kill me (in other words, options are not necessarily bad).

      People being responsible for themselves and their choices isn’t a bad thing, either, and if someone ruins their install because they weren’t reading instructions or didn’t understand how things work (that’s why you get help!), it isn’t WordPress’ fault, either.

      I personally can and will take responsibility for my choices and nothing in life is ever perfect including web publishing platforms. It’s called being an adult and I’m not going to point my finger at WordPress.

      … Unfortunately, I am not the most PHP-savvy person and if, in the future, I decide that I do NOT want automatic updates (I like updates, don’t get me wrong; I just want to be able to educate myself first, make a backup JUST IN CASE, and make the choice myself, thank you!), I’m not sure if I would be able to disable the functionality without some kind of problem and this is something that concerns me.

      Ultimately, beyond just security and very minor necessary automatic updates, I want CHOICE, not decisions made for me.

      I chose WordPress as my web publishing platform out of choice because even though it isn’t perfect (and nothing in life is), it has what I need and that includes the variety of options and out-of-box customization features available. Please don’t take my choice to have my options away from me in the future.

      Thanks for reading!

      • Andrew Nacin 4:00 pm on October 27, 2013 Permalink

        Great comment! Ultimately, I think we are years away from even considering automatic updates to major releases. The update technology is here now, but we have so much more to do to get to the point where we can be confident in each and every major release. Things like dependency resolution, detecting possible incompatibilities (including between two plugins) before we update, detecting and fixing all kinds of failures after we update, etc.

        There are also a number of intermediate steps we could take on the way there. For example, we could suggest an automatic update across major versions — but only once the .1 is out.

        • EMG 11:34 pm on October 27, 2013 Permalink

          Thanks much for the additional thoughts. :) It is reassuring to get a glimpse into the thought process involved in such a thing.

          I read the articles you linked to for another poster and I can understand the thoughts (well, at least a good majority of them) that went into making the choices involved in this auto-update business.

          So here’s a question: Let’s suppose in looking to the future and WordPress reaches a point where auto-updates on major releases is a viable possibility. At this point in time, would it be unreasonable – given the fact that we are now talking about major updates and not just security patches or minor fixes – to request that auto-updates for such a thing be made absolutely optional?

          I’m thinking how you’re thinking in regards to what you said about testing for compatibility and making sure there are backups and what-ifs about potential upgrade failures, etc, and it seems like in that case, the potential troubles involved with auto-updating outweigh the benefits of auto-updating.

          As an advanced end user, I am therefore wondering if there is a reassurance to be had in regards to always having an option – even if it’s more advanced like in the examples you stated in this blog post – to be able to SAFELY disable such a thing without ‘hurting’ the core files.

          In particular, I am thinking maybe automatically including in a plugin that would safely turn such a feature on or off?

          After reading your other posts, I am thinking in particular about the post you wrote about Firefox removing the checkbox for the disabling JavaScript function and your own comment about how you used an Extension/Add-on (I can never get the two straight) to do the same job.

          I myself as a front-end web designer (X/HTML and CSS, less of the PHP) use extensions/add-ons in a similar fashion… including disabling JS, custom stylesheets, and other things when I am troubleshooting websites.

          It makes me wonder if this what end users of WordPress are being encouraged to do?

          Rather than keep all the various options and choices all within the core, in order to offer a potentially more stable and easier-to-QA/beta test, the options are disabled in the install … but are offered instead as ‘extensions/plugins/add-ons’?

          Would love to hear your thoughts on this; the conversation has given me more food for thought for sure.

    • Peetra 10:46 am on October 27, 2013 Permalink

      I am not happy with these options to disable the update mechanism, there should be a simple tick box in the back end for this!

      I want to make my updates when I am online myself because it gives me the safety of having fresh backups if something goes wrong.

      • Andrew Nacin 4:02 pm on October 27, 2013 Permalink

        You are clearly a developer or power user. You have the ability to disable the update mechanism by installing a plugin or changing your site’s configuration. Beyond that, it’s our duty as developers to make smart decisions and avoid putting the weight of technical choices on our end users.

    • WPDogger 1:20 pm on October 27, 2013 Permalink

      This is a very naive and misguided change to WordPress. I understand the rationale, but one size does not fit all. Automatic updates have not worked on our VPS server since we were forced to lock it down due to thousands of attacks on our WP sites. If the automatic update is run, it fails every time and the site is shut down with the maintenance screen.

      I’ve seen the same thing happen randomly when some of our clients run the automatic updates on some GoDaddy servers.

      This needs to be a simple checkbox to turn it off or on.

      • Andrew Nacin 3:52 pm on October 27, 2013 Permalink

        No. It’s our duty as developers to make smart decisions and avoid putting the weight of technical choices on our end users.

        Have you even tried automatic updates on your VPS server? If it can’t modify the files, it won’t try to go through with an update. You are welcome to email me and I will personally diagnose your problems with automatic updates and make any adjustments to WordPress core that are necessary to avoid problems in the future.

    • AITpro 3:59 pm on October 27, 2013 Permalink

      @ Andrew Nacin – Quick question:
      I would like to force a real world WP auto-update for testing. Specifically I am looking for the best approach to triggering the wp_maybe_auto_update cron to simulate a real world update check from WP. I can do this manually in testing, but I would actually like to simulate a “hands off” test, which I can do with my API Server, but was just wondering if you guys already have something in place for this type of test where I would actually be getting the response from WP. Auto-updating ROCKS!!! Total awesomeness!!!

      • Andrew Nacin 4:10 pm on October 27, 2013 Permalink

        All you need to do is call wp_maybe_auto_update() or do_action( 'wp_maybe_auto_update' ). The best simulation is to run it in logged-out context (so, a different browser, or private browsing mode); otherwise, that’s about it. I ran test updates a few hundred times in 3.8.

        If you’re running a development version (or are forcing the automatic_updates_send_debug_email filter to true), you’ll get an email at the conclusion of the update.

        If you’re more adventurous, check out https://gist.github.com/nacin/7047909.

        • AITpro 4:29 pm on October 27, 2013 Permalink

          Perfect! So my assumption is that by doing this, this will create/force the wp_maybe_auto_update cron DB entry to be entered instead of having the cron scheduled if there were some kind of failure on the first attempt correct? Just looking for a yes or no on that. Thanks man. Your ROCK!!!

        • AITpro 4:42 pm on October 27, 2013 Permalink

          Disregard. Just tested and confirmed my question. Thanks again!

          • AITpro 6:28 pm on October 27, 2013 Permalink

            DOH! I’m a dummy. wp_maybe_auto_update is a standard WP Cron @since 3.1.0. LOL

            • AITpro 6:42 pm on October 27, 2013 Permalink

              Ok maybe not a dummy. This cron was added as a standard cron in 3.7. ;)

    • Central Geek 4:41 pm on October 27, 2013 Permalink

      Running multiple WordPress sites myself, I am not happy with the short sightedness of WP core developers requiring users to go into each site files and make changes to “Opt-Out”. While you are getting better at releases not killing sites, there are too many variables that can have a negative effect on a site by allowing unattended updates.

      All this automatic Opt-In shows me is how little you believe users would check a box which might say “Enable minor and security automatic updates”. I think (and this is only my thoughts), WordPress just stepped into the babysitting arena. Most of us are adults and can handle out own sites. Give us the option in our settings to turn on or off these automatic updates. You have given us the options to do so many things in settings, why force us to “Opt-Out” of this change.

      Your statement, Andrew “Beyond that, it’s our duty as developers to make smart decisions and avoid putting the weight of technical choices on our end users.” is erroneous, IMO. That statement reeks of a condescending attitude.

      Requiring users to go into files to turn something off is, in fact, placing the weight of technical choices on your end users, if they don’t want to run the risk of an update that doesn’t go right, thus shutting down their site.

      I don’t agree with your logic that you have made a smart decision to automatically do “minor and security” updates. Even our servers (those of us who have our own VPS or Dedicated Server), give us the option to do updates automatically or manually, the software running on it. There is good rationale for that. THINGS GET BROKEN.

      Doing updates without giving the end user the option to backup, before such updates is one of the worst decisions I have seen WordPress developers make. I don’t care how “confident” you are, if there is a need for a security update, there is something somebody missed. That, in and of itself, gives me pause when thinking about allowing you to automatically update my sites.

      Give us the option to turn on or off this stroke of genius spawned by the Google and Facebook automatic “Opt-In” practices.

      I personally see this change as a total lack of “confidence” in the end users ability to keep up with updates. You do not have the obligation to remove the option for us to make our own decisions.

      I see you are defending this choice WordPress has made, pretty aggressively. Just make the change and allow us to make the choice, ourselves.

      I love working with WordPress, make no mistake about that. But this decision is one of the worst WordPress core developers have made. There are just too many variables that could cause an issue.

      Your own warnings have always been, Backup, Backup, Backup before an update. Now, within one version, you have become so confident that you throw that important advice to the wind and want to automatically update? I think not.

      I hate to say it, but that rationale sounds more arrogant than smart. Forgive me if that is offensive, but this is no small matter.

      Telling us that it is your obligation not to put “technical” decisions on the end users, while explaining to us the technical process of disabling or modifying what you have done is almost laughable.

      • Andrew Nacin 5:15 pm on October 27, 2013 Permalink

        Well, I am not happy with the shortsightedness of your post.

        There will never be a checkbox in WordPress core to turn off security updates. Ever. I’m not happy with developers thinking we should just let sites be insecure because reasons. Under what circumstances should a user not want security updates? Offering that as an option would be an abomination. It would be the most stubborn, amazing example of open source catering to a vocal minority at the inconceivably large expense of its end users. Security issues do not cause hypothetical issues. They cause real, direct, serious harm. I’m not trying to be dismissive — you simply are not the target market for this decision.

        WordPress sites serving malware doesn’t just hurt that site, or even the brand of WordPress — it hurts every user on the internet. With WordPress powering 20 percent of the internet, a day rarely goes by where someone on the internet doesn’t visit a site running WordPress. We must not be ignorant about this.

        I’ve written extensively on this subject. For more, read Firefox makes a decision, removes an option, our own philosophies page, Checkboxes that kill your product, and numerous essays written by Havoc Pennington.

        It’s worth nothing that nothing short of the reputation of WordPress — not to mention my own reputation — is at stake here. If “THINGS GET BROKEN,” how do you think I’m going to sleep at night? Given my skin in the game here, I wouldn’t be so confident (call it arrogance if you’d like) if I didn’t have very good reasons to do so.

    • Central Geek 6:22 pm on October 27, 2013 Permalink

      I never said turn off security updates. I said give us the option to turn off “automatic” updates. There is a major difference.

      I am not hosting my sites with WordPress.com, I don’t want WordPress and it’s developers deciding for me what I have and what I don’t have automatically updated. Give us the option in our settings to turn on or off the automatic updates. I don’t care what you think is best. I am not asking for you to tell me how to run my sites.

      If I want to backup my sites prior to an update, I should have that option by my settings. Not me going through the technical process of accessing files and making changes to them.

      Your response is another indication of the attention to detail WordPress developers seem to be lacking at this time. You didn’t even clearly understand what I said. And you jumped on what you presumed I was saying, even though I was clear that I was suggesting the option to turn off the “automatic” updates, not updates altogether. You haven’t provided me with sufficient evidence that would support my being that confident in your ability to decide whether my sites should be updated automatically by you or the rest of the core developers without giving me the option to manually allow background updates after I backup my sites.

      • AITpro 6:57 pm on October 27, 2013 Permalink

        Take a look at the code in /wp-admin/includes/class-wp-upgrader.php and you will see FailSafes after FailSafes after FailSafes…….. If you do not want WP autoupdates to happen on your site then add the Constant in your wp-config.php file that is clearly posted above to turn off Core updates.

        • Central Geek 7:06 pm on October 27, 2013 Permalink

          The point is this. The statement was made, “Beyond that, it’s our duty as developers to make smart decisions and avoid putting the weight of technical choices on our end users.” and then there is the description of how to go about (through technical process) making changes to the wp-config.php file one by one, for each site, to disable automatic updates.

          I know how to do what was suggested. I don’t think it should be required for anyone to go through that process to opt out of WordPress imposing these automatic updates on users, because they either don’t like the fact that some people don’t do those updates on their own, or for some reason WordPress has adopted the notion that we aren’t capable of knowing what is best for our sites.

          I don’t care what failsafes are in place. There is opportunity for something to go wrong. Even possibly a flaw in the update itself, which without allowing for backups prior to such updates, could cost users valuable information. We have no way of knowing when these updates take place ahead of time. Allowing the simple option in the settings to turn those automatic updates off, without having to manually go into the wp-config.php file, would be a smart decision, not the other way around.

          • AITpro 7:14 pm on October 27, 2013 Permalink

            You do have a valid point in general, but what I think what is very important to focus on is these autoupdates are “minor” updates and not “major” updates. A major update might have the potential for a problem, but a minor update is basically just a patch of sorts. I guess if there was a coding mistake in a minor update then it could cause a problem, but obviously before WP releases anything it is tested, retested, tested again and then maybe tested 100 more times. ;)

            • Central Geek 7:25 pm on October 27, 2013 Permalink

              Yes, I am quite sure there is a lot of testing that goes into any update. And the best of efforts has proven in the past, to have adverse effects on sites. Minor or major updates, WordPress and it’s gurus have (until this point in time) made it very clear that backups should be done before “ANY” update.

              Now, they seem to have abandoned that suggestion and are now saying “As long as we do these “minor” updates for you, you have nothing to worry about”. I don’t buy it. I don’t care how careful they are, writing code for something that has so many plugins and themes (in the repository) that have code that does not conform to WordPress “suggested” practices, too much can go wrong.

              If WordPress enforced a standard, things might be quite different, but they don’t do such enforcement. There is where the weak link is in the logic of this “Automatic Updates” change.

              Even the biggest software manufacturers acknowledge that as long as other software (which they do not require to conform to their standards) is working in conjunction with their software, automatic updates should be an option that is in their settings. This is my argument.

            • AITpro 7:34 pm on October 27, 2013 Permalink

              Yep, it is a standard to provide an option to turn something on or off and WP is offering this with Constants in the wp-config.php file. I am very comfortable with adding or removing stuff to the wp-config.php file, but maybe a lot of folks are not comfortable with doing that. I’m sure a plugin or 2 will be created to add this as an option to do this from that plugin, but it won’t be me who does that. ha ha ha.

            • Central Geek 7:41 pm on October 27, 2013 Permalink

              Yes, AITpro there is already a plugin that does turn this automatic updates feature off. I shouldn’t need to turn to a plugin to do what WordPress should do already. As they themselves say, more plugins, slows down a site.

              If a person has a lot of sites, it is very time consuming to access the hosting account, via FTP or otherwise, and go into the wp-config.php file and make changes. Just put an option in the settings and let it be set by the user. That’s all that needs to happen.

            • AITpro 7:45 pm on October 27, 2013 Permalink

              I guess what I don’t get is this. When you first install WordPress you need to add your DB connection information: username, password, etc. so adding…

              1. Disables all core updates:

              define( ‘WP_AUTO_UPDATE_CORE’, false );

              …to the wp-config.php file is pretty much that same thing to me. ;)

            • Central Geek 7:52 pm on October 27, 2013 Permalink

              That’s well and good if you are creating a new, or fresh install. That might be reasonable. But when someone either has multiple sites or is managing multiple sites, it’s not that quick. Have you tried working with 100 sites or so? It’s more than enough to have to go to the settings and turn on or off, but that is a reasonable expectation. Requiring the accessing of wp-config.php to do all of those sites is not reasonable. This should be a setting.

              Do you have a few hours you don’t have something else you could be working on? It is unnecessary to require that of users.. :)

            • AITpro 7:59 pm on October 27, 2013 Permalink

              Ah yeah 100+ sites @ 1-5 minutes a piece would take some time. I see your point now. Ok I have some spare time today so I’ll create a disposable plugin that will allow you to do this with one click. This should only take about 30 minutes to complete. I’ll post the plugin zip file for download in my Forum when it is finished.

            • Central Geek 8:01 pm on October 27, 2013 Permalink

              Too bad WordPress won’t do it, but thanks. :)

            • Ipstenu (Mika Epstein) 8:22 pm on October 27, 2013 Permalink

              Re editing wp-config – A lot of people use one click installs from their hosts and never edit the config files.

            • AITpro 9:42 pm on October 27, 2013 Permalink

              heres the zip file: http://www.ait-pro.com/p3672/autoupdate.zip
              Keep in mind this is a very stripped down plugin – it only does one thing… Adds this WordPress Constant: define( ‘WP_AUTO_UPDATE_CORE’, false ); to your wp-config.php file directly below this text * That’s all, stop editing! Happy blogging. * in your wp-config.php file to turn Off WordPress Core Updates.
              Install the plugin zip file with the WordPress Upload Zip installer. Click the plugin’s Settings link, click the Add Constant to wp-config.php button. You will see a success message if the code was added successfully. You will see a “you have already done this message if you click the button again”. it is actually checking for the code in wp-config.php so it is a valid check.

            • AITpro 10:49 pm on October 27, 2013 Permalink

              I just add a Remove button as well. So this plugin now adds and removes the define( ‘WP_AUTO_UPDATE_CORE’, false ); Constant.

            • Central Geek 5:14 am on October 28, 2013 Permalink

              Thanks AITpro.

          • Andrew Nacin 5:28 am on October 28, 2013 Permalink

            While this post is called “the definitive guide to disabling auto updates” what it really is is a cookbook to tweak them to exactly what you want. It was a post written by a developer, for other developers, precisely to avoid the kind of confusion that has muddied this comment thread.

            If telling 100 sites to do the same thing requires a UI setting, you need to look at how you do deployment and management. From a pure maintainability standpoint, the last thing I’d want is a UI setting I’d have to consistently set, individually, across 100 sites. I’d want a constant I can deploy, or a plugin I can share, or something along those lines. If I’m managing 100 sites, it’s going to be easier for me to deploy code to all of them than it is to go into each dashboard. We are developers — we write code to solve problems! The belief that going into 100 dashboards to tick a manual checkbox is easy and preferred is strongly indicative of a very serious problem.

            • Central Geek 6:03 am on October 28, 2013 Permalink

              The belief that you are solving problems (which apparently are mainly in your logic) with an automatic update hard coded, which requires users to implement code to disable is flawed from the very beginning. It only takes one time for your rationale to fail to prove my point. You can get it right all the time, until that one failure and never prove my point wrong.

              Automatic Updates of any software, where “20%” of the internet is using that software, without allowing a setting to turn it off is inconsistent with most major active software on the market.

              When you write a post like what you have written, it is helpful to developers and non developers across the board. that is not disputed.

              The stubborn position taken that the decision to hard code something that requires “technical” processes to disable, while claiming that it is your responsibility to make “smart” decisions that take away the need for end users to make “technical” decisions is a VERY SERIOUS FLAW IN YOUR LOGIC,

              You can defend what has been done until hell freezes over. The decision not to allow users to disable it in their settings is wrong and a poor decision. Time will prove that out. You cannot (as a programmer) be right 100% of the time. It just doesn’t work that way, I don’t care how “confident” you are. In fact, that very confidence is an indication of a flaw in your logic. You will mess it up, WordPress history proves that out. Programming history in general proves that.

              Be as arrogant about it as you want, it won’t change the fact that only one time does a major site have to be taken down by a flaw in an update, and you have a VERY SERIOUS PROBLEM. People won’t have had the opportunity to put the update to any testing before updating their live sites. They won’t know where to look, except to WordPress, to get it fixed. WordPress does not have the support system to handle such a failure.

              Your argument fails on several, already discussed, points. Just put an option so that users can disable your automatic updates. While you may be an accomplished author, and have done a very good job on certain parts of WordPress code, the decision not to allow the average user to be able to disable automatic updates, without going through a technical process is wrong. Plain and simple.

              The whole argument is in stark contrast with the practice of allowing and urging users to back up their sites prior to them clicking on the button to update their website. Please explain the deviation from that logic, which has been promoted by WordPress all along?

              All it takes is for you to mess it up one time, the way you have decided is the best way. Yours and WordPress’ reputation doesn’t support the confidence you are requiring of users, in that area. Nor does the history of programming itself. This decision is not a wise one. Sure, it’s great for Google and Facebook who gather and sell their users’ information and make billions of dollars off of it, until they opt out.

              But, for a software that is being used by a large portion of sites across the internet, to remove the option for most of it’s users to easily turn off the automatic updates, it’s not the wisest of decisions. And again, time is on my side, to prove it out.

            • Central Geek 7:36 am on October 28, 2013 Permalink

              And Andrew, you are correct in your statement “The belief that going into 100 dashboards to tick a manual checkbox is easy and preferred is strongly indicative of a very serious problem.”

              The notion that Automatic Updates should be on by default is indicative of a serious problem. Making such decisions for users is not a practice that should be employed by any software, where there are thousands of plugins and themes that are not “required” to conform to the standards set by the platform being used.

              Automatic Updates should not be on by default. At the time of any update that would offer such a feature, the user should be given the option to turn that feature on. And explain to the user that the setting is available to turn it on or off in the settings, should the user change their mind. That is the way it should be done. So, we are in agreement with your statement there. But it doesn’t stop with that statement.

            • AITpro 2:44 pm on October 28, 2013 Permalink

              I agree with you 100% man that this topic has gone wild / off topic. Maybe split or move the posts starting from the point where this train jumped the tracks. ;)

            • AITpro 2:48 pm on October 28, 2013 Permalink

              Or just delete everything that is not relevant to the topic.

            • AITpro 3:15 pm on October 28, 2013 Permalink

              Just throwing an idea out there man to be helpful. What about creating a new topic for non-developer questions and concerns, move all non-developer questions to that topic. Get your Guide back where it is supposed to be and state this topic is for developer posts only and post the link to the non-developer topic. I’ve had to do this exact same thing several times on my Forum where my Guides get cluttered with personal questions, off-topic questions and other stuff that wrecks the purpose of the Guides. Just a thought man.

            • Helen Hou-Sandi 8:04 pm on October 28, 2013 Permalink

              I don’t know how to say this without sounding abrupt, so I’m just going for it: this is a developers’ blog. It’s about the development of WordPress core. It is not meant to be end-user or non-developer facing. An end user would be more interested in a plugin that gives UI for fine-grained management of automatic upgrade options, whether turning them off or enabling more of them, which as I understood either exists or will shortly in the original Automatic Updater plugin: http://wordpress.org/plugins/automatic-updater/.

            • Central Geek 6:09 pm on October 28, 2013 Permalink

              If I might be allowed to approach this from a different angle.

              With all due respect, Andrew (and I do mean respect), you and the other core developers have presented those of us who may not be coders, “developers” (in your sense of the word) or anything other than users to you, with an update that for all intents and purposes attempts to lock us into using your automatic updates without providing us a reasonable explanation for the change, or an explanation for the deviation from the backup, backup, backup rhetoric WordPress has been putting forth for quite a while.

              Because you offer us no simple solution to the automatic update default On, we begin to look for a solution. What we find is this post, which you say is “by a developer for developers”. Well, given that you (WordPress) don’t offer the normal, easy solution, we begin to comment.

              You may not want us here, but because of the change and the way you went about it, you now have us here. You (WordPress) created this situation by deciding for us what you believe we should have, because you don’t believe we should have the weight of such “technical” decisions on our shoulders.

              Like it or not, we are part of the same team. We are people who take your routines, and create from them something we want to present to the world, the same as you take someone Else’s language and create routines which we can use to accomplish our goals.

              We are all developers at some level, and we are (or should be) considered part of the same community. We are dedicated to the use of WordPress, we have a great deal of respect for those who have created the WordPress platform. At least give us the option to turn your automatic updates off in a simple way, so that we don’t have to bother you with our lack of knowledge and understanding of what you have knowledge and understanding of.

              If you want to know where the confusion came from, take a look at what you (WordPress) did and the way you (WordPress) did it. What else did you expect to happen, when you gave us no other options, except to wait for someone else to create a plugin to accomplish what you didn’t want to allow us to do via our settings?

    • sylvestercomputerguy 7:08 pm on October 27, 2013 Permalink

      We all know that doing the updates is generally a no-brainer.
      And we all know that there are basically two groups: Non-Coder Users and Coder Users of varying skill.

      For the non-coders, generally only responsible for their own website, I believe that having the autoupdate installed and active by default is a great idea, as it will make things better for everyone by patching up otherwise unsecure installations that may date back many many versions.

      However, for the coders who are likely in charge of other folks’ websites, I believe the problem is in the lack of choice on how those updates are accomplished, and the fact that some coders aren’t comfortable with anything beyond HTML and CSS, so the code switches may be a bit daunting.

      For coders who are more advanced, there’s just the hassle of going in the backend to see if it’s turned on or off on a particular site, then editing the file accordingly, when they are already in the admin interface where the change would be less steps. For both camps, a simple page with toggles for each of the code switches would give an easy visual way to know which way each site is configured, and an easy way for all to modify them.

      I don’t believe we are actually debating the merits of doing the updates, or the faith in WP that they won’t blow up stuff (although weird things happen when dealing with third party plugins/themes/hosts, and sometimes we like to be more safe than screwed), it’s more that coders responsible for other sites would rather feel more confident about how things are set, and a toggle quickly shows status while also providing a fool-proof way for changing the setting.

      I join in the request to add visual toggles that will effectuate the same switches that are currently required by code. If nothing else, if WP wants to keep the decisions out of lower level hands, perhaps a green/red indicator to let us know if it’s set to ‘auto’ or ‘manual’ update so it’s easy to tell without fishing in the backend.

    • sylvestercomputerguy 7:40 pm on October 27, 2013 Permalink

      This looks like it might be what we are looking for http://wordpress.org/plugins/automatic-updater/screenshots/

    • Gtantra 7:56 pm on October 27, 2013 Permalink

      Central Geek does have a valid point . I too was concerned about the site breaking . Now I do understand that the updates are minor , and minor updates are tested, tested and re-tested – But non of these testing is done with the third party theme’s we install on the site ( as well as the plugins installed ) . So where is the guarantee that it can’t break ?

    • subpopet 9:09 pm on October 27, 2013 Permalink

      Autoupdates broke my site (kept redirecting me to the home page), had to reinstall 3.7

      • Dion Hulse 12:00 am on October 28, 2013 Permalink

        WordPress 3.8-alpha nightlies had an issue yesterday where only the front page would load. The next nightly release would’ve corrected it, but when you’re using the bleeding edge (3.8 in this case) breakage is expected occasionally and shouldn’t be run on a production site (although many of us do, I had the same thing happen to me).
        So it wasn’t the autoupdate that broke, it was an untested nightly release with a bug.

    • linkomatic 2:39 pm on October 28, 2013 Permalink

      This is such a strange discussion, complete with entrenched positions and comments that border on personal attacks. I’ll try to avoid both. I owe my livelihood to WordPress, and am eternally grateful to the people who support it. So, I’m not out to rip anyone a new one — but EVERY process can be improved. I don’t have an axe to grind, but I do have opinions. These comments are offered in that spirit.

      First off: the communication about what changes this release brings, esp. WRT the auto-update process. I THINK I understand which releases will be auto-updated, but that is not specifically called out in either the blog posting or the release notes. And there is no mention of what happens when, for example, you have installed version 3.7 installed and the newest version is, say, 3.8.2. Would it be possible to explain this further so that someone who is not a WordPress “insider” could understand exactly how this process will work? That would be very helpful.

      That aside, I agree strongly with several of the commenters who are asking for a simple, non-intrusive way — a “checkbox” if you will, not requiring editing wp-config or adding plugins — to control whether WP updates automatically when “maintenance and security” updates are available. Here’s why…

      It has been beaten into me — time and again — by various WP security experts to ALWAYS take a backup before applying ANY kind of software update, including any type of update WP core update, lest you want to place your site at risk for an update breaking your site. And I beat this same message into my students, too. (I teach classes in WordPress.) Why should this change now? Because the core team tells you it’s “safe” to assume there will be no problems? Sorry, as much as I’d like to believe that, old habits (esp. regarding site security die hard). So, I’m not going to change this practice any time soon — at least until there is a clear track record of auto-updates resulting in ZERO failed sites. (Not sure how WP can track this — so, that probably means I’ll never deviate from the practice of taking backups before updates.)

      The question then becomes: is it too much to ask someone to install a plugin or edit wp-config to turn off the auto-updates? My vote: YES it is. Whether you manage one site or hundreds of site, the option to turn off auto-updates should be as simple and straightforward as possible. Looking at it again from the perspective of one who teaches WordPress, most of my students are very non-technical people. If there were a way to totally eliminate their need to edit wp-config, I would vote for that. (Hey, how about adding a script to assist the “Famous 5-minute installation process” that would prompt users for the values they need to provide??? Now THAT would be a real improvement!) So, I’m not going to direct them to an obscure blog post (like this one) to tell them what to do.

      And a plugin to do this? Really? Another thing I have been taught — and I teach my students — is: the less plugins the better. How exactly is a plugin somehow better than a checkbox — a checkbox that defaults to “YES, please apply maintenance/security updates automatically”, a box you have to UN-check to disable? You could even add a warning on the screen: “Don’t uncheck this box unless you really know what you are doing.” This solution seems to be totally in the spirit of what you want WordPress to be: simple solution that empowers users. And core developers are doing their job, and everyone can sleep at night.

      Thanks for listening.

      • Central Geek 4:35 pm on October 28, 2013 Permalink

        linkomatic,

        You said everything I was trying to say and did it much better. I am probably one of those who seemed to border on personal attacks, which was not my intent.

        I have a great deal of respect for all of the core developers of WordPress, as well as those who contribute. The last thing I want to intentionally do is attack them. But I am also one of those who is entrenched because of the very same reasons you state in your comment.

        Why change the logic of backups before updates? And if this is to change, why not give us a good explanation for why we should trust something that hasn’t had a good track record until the most recent update, prior to 3.7?

        I’m all for jumping on board, but make it make sense, and make it simple. The processes being explained are not simple. That is outside of the very foundation of WordPress, which is supposed to be simple.

        Much better presented than I, thanks.

    • wprick 3:01 pm on October 28, 2013 Permalink

      So let me ask this. If and when there is a minor security update or a minor bug update and it breaks the users site. Does the auto update then fix the break when it happens. Will it be fixed in a timely manner where sites that do and will eventually break because no one is perfect all the time. How will it be handled if this happens? I am for the updates but at the same time I want to feel secure about any updates that I have no control over to be fixed so the site is not down for any real length of time.

      Also, how will we be informed that there has been a flaw when it arises because it surely will at some point in time do to imperfection by even the most brilliant of coders. How will the end user know that the result of the break is from a minor security update or bug patch. Will we be sent emails or such notifying the end user of the flaws when they arise because they will eventually.

      How do we determine whether it is a beak in a plugin, a theme related problem or anything else for that matter. I would rather not live with a guessing game when it comes to a broken site and not know if it is a result of a backend update that is hidden. Again I am for the auto updates but with some kind of plan in place for when a site has faulted do to a hidden update.

  • John Blackbourn 12:00 am on October 25, 2013 Permalink
    Tags: 3.7, ,   

    JSON Encoding and SSL for api.wordpress.org Communication in WordPress 3.7 

    There are two changes to the way WordPress communicates with api.wordpress.org in 3.7: JSON encoding and SSL.

    JSON Encoding

    In versions prior to WordPress 3.7, data that WordPress sends to (and receives from) api.wordpress.org is serialized using PHP’s native serialization functions. PHP-serialization has two main problems:

    • Security: It has the potential to lead to security exploits via PHP object injection.
    • Portability: It’s hard to unserialize these strings in other languages besides PHP.

    In WordPress 3.7, most API calls have now changed so they send and receive JSON encoded data instead. The three major ones are:

    • Core update checks
    • Plugin update checks
    • Theme update checks

    The following calls have also changed, but you’re probably not so interested in these:

    • Importers list
    • Credits list
    • Browse Happy (the browser version check)

    How might this affect plugin or theme developers?

    In general this won’t affect developers at all. If your plugin or theme just consumes the API then you don’t have to make any changes. The API calls that send and received JSON encoded data have all had their version numbers bumped from 1.0 to 1.1 (for example, api.wordpress.org/plugins/update-check/1.1/. If you are consuming the version 1.0 endpoints you’ll continue to get PHP-serialized data. If you want JSON encoded data, you can switch to using the version 1.1 endpoints.

    There is one situation that developers may need to account for. If your plugin or theme hooks into the update API requests in order to remove certain plugins or themes from the update checks, your code may need updating.

    A common method for removing a plugin or theme from the update checks is to hook into http_request_args, unserialize the data being sent to the API, remove the given theme or plugin from the data, and serialize it again. This will no longer work in WordPress 3.7 and your code will need to be updated so it decodes and encodes the data as JSON instead.

    An example of a plugin which has been updated to handle JSON encoding along with fallback support for PHP-serialization (depending on the version number in the API call) can be seen here: https://github.com/cftp/external-update-api/compare/f4d58e2…281a0ef

    Note that there are two API calls which have not yet changed to using JSON encoding:

    • Plugin info
    • Theme info

    These two calls will most likely be updated to use JSON encoding in WordPress 3.8.

    SSL Communication

    As part of the hardening process of this release, WordPress 3.7 will only communicate with api.wordpress.org using SSL (HTTPS) when the server supports it. This is an especially important security enhancement, given that automatic background updates are now a part of WordPress. Indeed, automatic background updates are disabled if the server cannot communicate securely with the api.wordpress.org.

    How might this affect plugin or theme developers?

    Again, this won’t affect developers in general. If your plugin or theme hooks into API calls you may need to update your code to it handles calls to https://api.wordpress.org/ in addition to http://api.wordpress.org/.

    JSON encoding and support for SSL means the WordPress.org APIs are in a much better position going forward.

     
    • Lester Chan 1:00 am on October 25, 2013 Permalink | Log in to Reply

    • djmceltic 8:17 pm on November 5, 2013 Permalink | Log in to Reply

      I have installed 3.7.1 cleanly on a server with SSL. The server is behind a firewall and many of the admin features are broken out of the box. Not sure what the fix is for this but it seems like there might need to be more configuration during install for SSL if you are going to force it.

      • John Blackbourn (johnbillion) 8:25 pm on November 5, 2013 Permalink | Log in to Reply

        Could you get some details of your server together (name and version of the OS, web server, TLS (OpenSSL/GnuTLS/etc), details of the firewall) and post a ticket to Trac? Thanks!

        • djmceltic 12:42 am on November 6, 2013 Permalink | Log in to Reply

          Hi John

          Windows 2008 R2 PHP 5.4.16 MySQL 5.5. With 3.6 and earlier we have had issues behind the firewall searching for plugins and themes and simply didn’t use this functionality – just did uploads. We have about 40 different WP installs (many different versions – couple haven’t been touched in years) and these are all working fine on same server.

          It looks like WP sees that I have ssl running on sever (which I do) and then whenever in the code we see if ( $ssl && is_wp_error( $request … it returns the warning message – PHP Warning: An unexpected error occurred. Something may be wrong with WordPress.org or this server’s configuration. If you continue to have problems, please try the support forums. (WordPress could not establish a secure connection to WordPress.org. Please contact your server administrator.) in C:\inetpub\wwwroot\ticket\wp-admin\includes\theme.php on line 298 – or whatever line the error comes from.

          It doesn’t happen on the update link which I find odd but happens on themes.php and install-plugin.php and a couple other areas.

          It is frustrating to think that we have to have an internet connection to change a theme or install a plugin. I work offline on my laptop all the time. But to fix the server issue is there a way to tell WP that we don’t want to use ssl? Or is there any other suggestions (I have tried adding my proxy server and all of that stuff in the config and no help)? Also our proxy does pass ssl urls – so not really sure if this is an ssl issue or proxy issue or both.

          • Dion Hulse 12:54 am on November 6, 2013 Permalink | Log in to Reply

            This sounds like you’re having connectivity troubles or latency issues, the WordPress.org API’s have a timeout of 3 seconds, if you exceed that it doesn’t work.

            Plugin/Theme update checks however have a 30 second timeout when run via Cron, so they’re probably succeeding which explains why updates work but installs don’t.

            So this is probably completely irrelevant to SSL by the sound of it, You might want to increase the timeouts for connections:

            add_filter( 'http_request_timeout', function( $timeout ) {
               return max( $timeout, 10 ); // minium of 10 seconds as a default timeout for HTTP
            } );
            

            Yes, it’s frustrating that you have to be online or with an internet connection for Update Checks and Install-from-web to work, Core Developers suffer the same problems sometimes, but, WordPress is a web-app and expects to operate in an online world, there are constants available to block outgoing HTTP requests when running in a locked-down environment though (See WP_HTTP_BLOCK_EXTERNAL and friends)

            • djmceltic 1:22 am on November 6, 2013 Permalink

              Dion

              I am fine with those updates requiring you to be online – but not just switching between already installed themes and plugins.

              Also the issue I detailed is not a proxy server timeout issue. I just installed 3.7.1 on server on same LAN as my web server that does not have SSL and it works fine. Not sure why but SSL is killing the apps. And the warnings I am getting are directing me to lines looking for $ssl = true.

      • Dion Hulse 11:29 pm on November 5, 2013 Permalink | Log in to Reply

        Not quite sure what the issue is, is it, a) SSL is broken in your install, b) Firewall blocks HTTPS but not HTTP? c) Firewall blocks all outgoing HTTP/HTTPS, d) Something else?

        Either way, create a trac ticket as John said if it’s something we can fix.

  • Andrew Nacin 10:03 pm on October 23, 2013 Permalink
    Tags: 3.7, rest, scotch   

    The current plan is that WordPress 3.7-RC2-25890 will be the last build of 3.7 before release. Download it here: http://wordpress.org/nightly-builds/wordpress-3.7-latest.zip.

    Trunk (and thus the bleeding edge nightly) is 3.8-alpha, but other than the version number, the builds are the exact same.

    Per the developer meeting today, we’ll be meeting at Thursday 14:00 UTC in IRC (#wordpress-dev) to see if everything is a go.

     
  • Andrew Nacin 5:34 pm on October 18, 2013 Permalink
    Tags: 3.7, blamenacin, mkdir_failed_pclzip   

    Have you been receiving update failures with the error code mkdir_failed_pclzip? Then why haven’t you reported it? ;-)

    So, on October 14, I accidentally committed a change that deliberately raised this error when PclZip was used to extract downloaded ZIP files. If ZipArchive is present, it is used instead of PclZip, so this doesn’t affect most installs by default. But, there are a lot of installs that do use PclZip, and they are “stuck” on the October 14 nightly build, and are unable to update past that point.

    So, a few options to fix this:

    • You can download the latest nightly build (or WordPress 3.7 RC1 will be released soon) and manually install it. (You probably just need to copy over the file wp-admin/includes/file.php.)
    • Or, you can open up wp-admin/includes/file.php, head to about line 747 and remove the comment on the if statement, as was done in changeset 25799.
    • Or, you can install the Zip PHP extension. :-)

    Of course, it is absolutely critical that an install is always able to update, even in development versions. @dd32 and I take that very seriously. Sorry for the lapse.

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

      *cough* I didn’t report http://wordpress.org/support/topic/wordpress-failed-to-update-to-wordpress-37-beta2?replies=16 upstream because I saw that once people updated manually, it was fixed, which told me that it was already fixed in core, and people were just unlucky in getting it. Looked like a relatively small subset too.

      Mea culpa. Normally I’m better about that!

    • Fretless 6:14 pm on October 18, 2013 Permalink | Log in to Reply

      Haven’t had a problem with auto-updates so I’ve not noticed. Obviously using ZipArchive on my server…

    • programmin 9:36 pm on October 18, 2013 Permalink | Log in to Reply

      I was curious, is there a technical reason for not auto-updating when using ftp setup? AutoFTP for example.

      • Andrew Nacin 6:17 pm on October 21, 2013 Permalink | Log in to Reply

        When we can’t own files we create, we avoid direct filesystem methods and instead request FTP credentials from the administrator. But, we don’t store the FTP password anywhere.

        If you choose to add your FTP password to your wp-config.php file, then we’ll do an automatic background update via FTP. That said, it’d be faster and more reliable if you changed your setup so we could do direct filesystem methods.

  • Andrew Nacin 5:29 pm on October 16, 2013 Permalink
    Tags: 3.7,   

    Agenda for today’s meeting in #wordpress-dev at 20:00 UTC.

    • Go over the last few days of progress, as well as what we’ve been learning via statistics for background updates. (Spoiler: excellent.)
    • Need a commit or revert on #20316 (garbage collect transients). It has a patch — the queries need testing and review.
    • Need a decision on #24963 (IIS stuff).
    • Finalize the about page. It’s going to be text-heavy as there’s nothing to show off UI-wise. What about a single giant three-column image across the top? I mean, it can be a picture of a sunrise for all I care. Or some screenshot of the WordPress admin. Or some photos from the crowds at WordCamp San Francisco and WordCamp Europe. Anyone have any ideas?
    • WordPress 3.7 Release Candidate 1 (by tonight).
    • Branch WordPress 3.7 (after RC1).

    @dd32 and I are working on #10787 this afternoon as well.

     
  • Andrew Nacin 7:38 pm on September 25, 2013 Permalink
    Tags: 3.7,   

    Meeting today: Road to WordPress 3.7 Beta 1 

    For the meeting today (starts in ~20 minutes), we need to work on getting to 3.7 Beta 1. I think if all goes well, we can release Beta 1 tonight or tomorrow morning. @dd32 has been doing some incredible work on automatic updates. If you haven’t read his post on them, please do!

    So, there are a few things we need to discuss and make decisions on:

    1. Search results ordered by relevance, #7394. Do we take a chance on this?

    2. Should we begin to require that users supply their current password in order to change their password? #20140.

    3. Should we consider a slightly more conservative different approach to transient garbage collection? We do not want updates to be blamed for breaking sites. #20316. What would this approach look like?

    4. How should individuals be notified via email when it comes to automatic background updates? #10787.

    5. How should individuals be notified their own dashboard that their site will be safe if there is a security release?

    Proposal for points 4 and 5: A green checkmark on about.php and update-core.php will let them know their install is OK and good to go for automatic background updates for security releases. (We can easily verify this without prompting the user.)

    If for some reason we attempt an automatic background update and it fails to complete, then we need to email get_site_option( 'admin_email' ). We need text for this email.

    If they don’t have a green checkmark, we should wait five days, after which we email them reminding them a security release is available. A timestamp five days from the point of release will be pushed via the API. Once that time is crossed, an email will be sent. (For a particularly critical situation, we could shorten the timeframe. For a non-security minor release, we might avoid having an email sent all together). We also need text for this email (which will be a fairly nice email).

    This does not accomplish all of #10787 (“Email administrators that an update is available for core, plugins, and themes”) but it seems to be a good security balance.

    ***

    My target is Beta 2 early next week, and Release Candidate 1 as early as next Friday. Here is our current progress on tickets:

    • There are no more enhancements or feature requests open on the 3.7 milestone.
    • There are under 20 tasks remaining for 3.7. Many of these are near completion. These need to be cleared by Beta 2.
    • There are 150 bugs open on the 3.7 milestone. We need to reduce this number to about 75 by Friday, and to zero by the end of next week. As in, these need to be cleared by RC1.

    We’ll likely branch 3.7 at the WordCamp Europe contributor day on October 7, which means anything that is punted out of 3.7 can still make it into 3.8 starting in just two short weeks from now. A reminder, this is a very short release cycle, and 3.8 is just a few months away and begins in earnest very soon. Here is what our philosophies document says about fast, agile release cycles with crisp deadlines:

    The more frequent and regular releases are, the less important it is for any particular feature to be in this release. If it doesn’t make it for this one, it’ll just be a few months before the next one. When releases become unpredictable or few and far between, there’s more pressure to try and squeeze in that one more thing because it’s going to be so long before the next one. Delay begets delay.

    If we’re not confident that three weeks is long enough for something to properly soak in trunk, let’s not be afraid to wait until 3.8.

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

    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: http://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!!
      (http://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.

  • Brian Richards 9:49 pm on September 17, 2013 Permalink
    Tags: 3.7,   

    Inline Docs Progress for 3.7 

    After last week’s weekly Inline Docs meeting we decided to begin doing a weekly ticket triage on Wednesdays.

    As of last Wednesday, we’re happy to report that 19 patches have been committed to core from 12 different contributors. We’ve also updated the original make/core post to reflect the files that have been completed (please go claim some!). You can see the full report of last week’s triage on Trac. It’s really spectacular, and you should show some gratitude towards Drew for putting the report together.

    Finally, beginning this week, our weekly inline-docs office hours are moving to #wordpress-sfd on Freenode. They’ll continue to be held on Wednesdays at 18:00 UTC, and we hope you can join us!

     
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