Cancel

Jeff Chandler

Automatic Updates Possible In WordPress 3.7

wordpresslogoAs was stated by Matt Mullenweg in his State Of The Word 2013 at WordCamp San Francisco, one of the goals for WordPress was to perform automatic updates similar to the Chrome browser. That is, perform automatic updates without breaking anything to the point where you don’t even know the software has updated. On the Make WordPress Core blog, we find out how this will possibly become a reality with WordPress 3.7. A plugin created by Pento called Automatic Updater will be used as the framework to provide this functionality. The first step is for the automation of minor releases. For example 3.7 to 3.7.1 would happen automatically. Andrew Nacin outlines a number of tickets that need to be addressed surrounding this functionality.

One of the first comments on that blog post is from Joshua Strebel, CEO of Page.ly which is a large managed WordPress hosting service.

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

Andrew followed up by noting there will be a mechanism to opt out which will not be accessible from the user interface. Instead, it will most likely be a filter or a constant to not only opt-out of upgrades, but also to enable upgrading to major releases as well in case you wanted full-blown automation. However, they are looking for more feedback from hosting companies and are encouraging them to follow the development of this feature.

Back around September of 2011, I asked whether Automatic upgrades for WordPress should be opt-in? Out of 210 votes, 67% or 141 said yes while 69 voted no. At the time, I felt like WordPress wanted to hold my hand too much when it came to managing my install. However, I am completely fine with automatic upgrades to minor releases leaving me to upgrade to major versions when I feel comfortable doing so. The conversation in the comments following the poll are worth a read, even if the conversation was two years ago. It would be interesting to hear from those who participated in that conversation to see if their views have changed, especially since we now know that the default upgrade functionality will be for minor releases.

I’m just thinking you might want to consider more than the most obvious point of view about upgrades. When was the last time you upgraded Chrome? Did you know it upgraded itself, about twice a week? Did you notice? Did you care? That’s the kind of thing I think we should shoot for. You shouldn’t notice upgrades, they should just happen. And not fail, of course. – Otto

Hmm, Otto mentioned the way Chrome upgrades in 2011, Matt talks about it as the model for WordPress in 2013 and that’s the way we’re headed. Perhaps Otto has a future telling crystal skull?

Category:
Tags: , , , ,
56

56 responses to “Automatic Updates Possible In WordPress 3.7”

  2. We also think that this is a great forward step for WordPress, initially for minor versions but hopefully for major versions in the future. There should be separate optin choices for minor and major versions (if/when introduced) and at least the minor version should be enabled by default. With WordPress being used so widely across the web, it could be argued that it has a moral responsibility to do this in order to ensure that security issues are automatically patched before they can be exploited. Another thought is that as most security issues are with plugins and themes, can some automated way of upgrading these be built into future plans as well

    Create forum topic from comment

  3. I like the idea especially for security updates, but it should be opt in for both major & minor releases and there should a way to easily roll back in case a vital plugin is slow releasing a compatible update.

    Create forum topic from comment

  4. Here’s what I said back then. I still agree 100% with that comment:

    I second what Eric Mann said: Automatic core updates should be OPT-OUT for new WordPress installations, but OPT-IN for existing WordPress installations.

    I’m all for the decisions, not options philosophy, but I’m also (and even more-so) all for the philosophy that, all else equal, new features in core should be disabled by default in existing installations, no matter how major or minor the feature. First, do no harm.

    And I would instantly enable the automatic core-update feature. What would be even cooler would be to have WP-CONFIG options to automatically update to RC and beta releases, or even to bleeding-edge nightlies. (Sure, I do this now, with Westi’s Beta Tester Plugin; but doing it via one line in WP-CONFIG would be even better.)

    And I agree with everyone regarding Plugins and Themes [not automatically updating].

    Create forum topic from comment

  5. @Chip Bennett – That’s a very very good point Chip. Opt-in for existing sites makes a lot of sense I think. Perhaps a dialog box could pop open prompting them to confirm they want to switch, as otherwise a lot of existing sites will never gain that new feature.

    A built in toggle for allowing plugins and themes to automatically update would be nice. I use the automatic plugin and theme updates on my own site, although I can totally see why others wouldn’t do that. I’m assuming at some point something will break for me, but I’m prepared for that.

    Create forum topic from comment

  6. Remember the “Post Formats UI in Core” feature of WordPress v_3.6?

    Remember the both palms flat on the table, firm eye-contact pronouncements, that “We will wait for the official account of what happened”?

    Of which, we never heard a peep or whisper?

    V_3.6.0 (RIP) tells us something that should stay foremost in mind.

    Leadership & developers at WordPress are standard-issue humans. They have advanced skills & special knowledge in specific contexts that exceed mine, and yours, in those particular contexts.

    I and you, on the other hand, have specific abilities in many other contexts that exceed those of personnel at WP-HQ, because those folks spend so (‘too’) much time & energy on their special context, permitting many of their standard-issue abilities to undergo a process of atrophy, occlusion, or delayed-development/expression.

    Look what’s happening at Google-HQ, right now. These are folks who became extremely successful within extremely constrained contexts, and now we find that as humans, core leadership there are still hung up in the dork-phase of life. Google might in fact never fully recover.

    Listen to the V_3.6 message. It tells us the key reality on Automatic Updates.

    Create forum topic from comment

  7. @Ryan Hellyer –

    Opt-in for existing sites makes a lot of sense I think. Perhaps a dialog box could pop open prompting them to confirm they want to switch, as otherwise a lot of existing sites will never gain that new feature.

    In my ideal world, this would be handled by a wp-config constant definition, with values of FALSE, 'core', or 'all', that defaults to “false”:
    if ( ! defined( 'AUTOMATIC_UPDATES' ) ) { $automatic_updates = false };

    On new installations, that can be pre-configured in wp-config, like so:
    define( 'AUTOMATIC_UPDATES', 'core' );

    That way, on existing installations, if the constant isn’t added, then the value remains at FALSE.

    And anyone who wants to opt-in to automatic updates for core, Themes, and Plugins can use the third value:
    define( 'AUTOMATIC_UPDATES', 'all' );

    Create forum topic from comment

  8. The problem I see with that plan Chip, is that older sites will not gain the automatic updating functionality. Most owners will not bother implementing the config and they are most likely the ones who need it most as they’re not staying up to date with the latest and greatest in WordPress. If they’re prompted to add automatic update support, then they probably will (particularly if it is encouraged via a dialog).

    Create forum topic from comment

  9. I was a Firefox user then I moved to Google Chrome (I like their sync feature), then I moved back to Firefox. When Firefox updates, any of my add-ons that are not compatible with that version get disabled. What if I NEED a feature of that add-on?

    So to make it with WordPress…what if a plugin is not compatible with WordPress, will it get disable or crash my site?

    I would say majority of plugin creators do the plugins as a side business and not their main job. So they can’t just go “hey boss, there is this man Matt Mullenweg who updated his software WordPress and now my plugin doesn’t work, can I take off a few weeks? yes I know you won’t be paying me, I won’t be able to pay bills…”

    From my perspective…what if the theme I am using, the creator gives up on it or moves on…that theme is not compatible with WordPress 3.7.
    I am not going to upgrade to WordPress 3.7 until I find a similar theme or a new one THEN I will update to WP3.7.

    Same for plugins, if xyz isn’t compatible…I will look for similar plugin THEN update to 3.7

    What about small businesses? You know, those people who have WordPress on their site and are not the most tech savy? Chip, Jeff, I might know how to f ix thing….they will be worried about how often updates come and if it will create conflicts with plugins/themes.

    I don’t care how much anyone says, WP can’t be tested with EVERY Theme/plugin on the rep, let alone themes/plugins outside the rep.

    There should be an option for me to update core/themes/plugins. Just like I have 7 plugins on my main site that need to be updated (I just noticed it this morning), I am choosing to update. Same with themes and core at the moment.

    I am willing to bet that most people in the WP Universe, do not update the exact second there is an update. Let’s say Jeff goes on vacation for a month. What if there is an update or two and conflict with whatever plugins he has?

    I had a conflict with a stats plugin and the mobile theme within Jetpack. I just deleted that stats plugin.

    Create forum topic from comment

  10. Thanks for the heads up. If this goes ahead I won’t be updating to 3.7, at least not until I can prevent it from auto-updating. I run a sandbox to test every update. I had a theme crash on 3.4 and it took a week or two for the theme author to repair it. The only way I could imagine auto-updating would be if there were a simple one-click rollback. If the auto-update did a backup first I’d be willing to wait for the upset peoples messages and then do the rollback. Of course I’d like to test this on a sandbox before committing the real site.

    Create forum topic from comment

  11. I agree with the idea that automatic updates should be an opt in feature. But to take this a step further, it should be an opt in selectable for each plugin. Automatic core updates should certainly be allowed. But some on some plugins automatic updates would be a disaster. Let’s take the recent NextGen Gallery 2.0 disaster as an example. I tried this update on a couple of my sites and had to go back to 1.9 fast. On another couple of sites I had applied 2.0.11 and then 2.0.14. The sites seemed to be running but then started exhibiting weird server behaviors and had to be back dates to 1.9. My point is had this plugin been automatically I would have been presented with about 20 sites in various states of non-operation—a total disaster. I use the misfortune of NextGen as an example, but they are not the only plugins I have had this sort of issue with. So allowing for selectivity of auto updates I think would be critical.

    Create forum topic from comment

  12. Fine if it’s OPT-IN only. But a nightmare otherwise
    If it’s not voluntary opt-in, it’s going to add another cost for my clients to bear, to mod the code. Why should customers have to fork out for something that should never have been considered in the first place.
    I second Patrick’s motion “there should a way to easily roll back in case a vital plugin is slow releasing a compatible update“. After the 3.5 disaster we (web support team) don’t update WordPress at all until a clients site has been thoroughly tested on an offline mirror site. We like making money, but not from bad decisions made by the good people at WP-HQ
    While there is a good case for automating security updates only, even this must be opt-in.

    Create forum topic from comment

  13. I think updates for existing sites should be opt-in. For new sites, it should be opt-out (but with a visual UI). We can use pointers to ask users to opt-in.

    Comparing WordPress to Chrome is not fair IMO. Chrome auto-updates, great. From an end-user point of view (me), if it breaks oh well. I’ll switch to Firefox no problems.

    If WordPress auto-updates, its effecting multiple levels of end-users: The website owner and the visitors of the website. I’m purposefully not counting the devs in this picture.

    Lets say something breaks and the website owner is sleeping or worst on a vacation… this can be a nightmare.

    On another point of view, there’s a plugin for that. Why bloat core when people can just download the plugin and get automatic updates. Those who want it will get it. People download plugins for caching, SEO, etc. Or we can just bundle the plugin like we do with Akismet…

    Create forum topic from comment

  14. Syed, it’s the people who don’t know they need it who need it the most. So having it as an external plugin does not achieve the goal of ensuring everyone is up to date. Those who who actively seek out the plugin, presumably keep their sites up to date already since they’re aware of how important that is.

    Create forum topic from comment

  15. Scenario #1 – Webmaster goes on vacation. WordPress updates itself in his absence trashing the site in the process due to plugin conflict or some other reason. He has a lot of work to do upon his return.

    Scenario #2 – Webmaster goes on vacation. WordPress pushes out a patch to fix a security vulnerability in his absence. Site becomes compromised before he returns. Not only does he have a lot of work to do upon his return there is a strong possibility visitors to his site could have had their systems infected if the site is now hosting malware.

    I can certainly see both sides of the coin here. Strong arguments can be made for both positions. Having said that, I would only support auto-update if it was an opt-in option for existing sites as others have already stated. If not, it will be the first thing I rip out on my sites.

    None of the software I use auto-updates – I’ve disabled that feature in everything I use, including Chrome. (although I rarely use Chrome) I prefer to be in control. I prefer to manually check for updates and install them when they are found. (which I do on a regular basis)

    Create forum topic from comment

  16. I don’t know about hiding automatic core update options.. I’d like (expect?) an easy way to switch them on or off without having to use a plugin or code. And I agree on separate options for minor and major core updates and no automatic updates for themes or plugins.

    Create forum topic from comment

  17. @Ryan Hellyer

    [I]t’s the people who don’t know they need [involuntary updating] who need it the most.

    WordPress themselves actively distribute thousands of outdated plugins (& themes), yet we are supposed to swing our approbation round onto the little people for not being all that concerned about updating?

    This might work better (more convincingly), if it were not the case that major systemic weaknesses of the installed WordPress base (18% of the Internet) arise thanks to behaviors and choices of expert SysAdmins who often have responsibility for whole networks of sites. Primary exploit-currents today are picking the pockets of well-positioned professionals …. not the tardy upgraders.

    It would work a lot more pleasingly, to propose that the unwashed need to be remote-controlled, if the New York Times was not right now on their lips due to shockingly reckless decisions & actions made by some of the most elite technology experts & enterprises on the planet. And we expect other global operations to follow them onto their faces …. even as the bullhorns blare the warnings, 24/7.

    With the Wall Street Journal gleefully eating NYT’s lunch, as the debacle proceeds.

    The problems of the Internet really aren’t going to be fixed, by squinting-down our eyes at those pesky WordPress crudniks who are wary of our inclination to run everything, for everybody else.

    Blaming update-laxity by the inexpert, is just looking for a scapegoat … for a complex reality that needs a more heads-up perspective.

    Create forum topic from comment

  18. If the next version of WordPress comes with a feature that the majority of users immediately want to turn off, or think they’ll never use, then we’ve blown it. To take it further: Any time you add a feature that defaults to off, why bother? WordPress should “just work”, and that includes new, important enhancements whenever WordPress is updated.

    We’re at the point where major releases are incredibly stable, and the maintenance releases are fixing usually only about a dozen edge-cases or security issues. This is in part driven by how we’ve shaped our release philosophies. And WordPress 3.7 plans to add even more stability to the update process, building off of a number of improvements over the last few releases, such as incremental updates.

    Opt-in (even just for existing installs) is a non-starter in my book. Think about it: If it’s important enough for us to add automatic updates to the latest security release, all sites should default to that track, immediately. Not doing so would be one of the most egregious instances in open source of bowing to the pressures of a vocal minority at the expense of the vast majority of users.

    One great thing about WordPress is it is open source, GPL, and highly extensible. We can aim for simplicity without preventing people to highly tailor their experience if that’s what they want.

    We can be really smart about this, like not doing auto updates when it doesn’t make sense to — such as when we can detect we are a Git clone or SVN checkout, or when updates are blocked from the UI, or when the web user isn’t the owner of core files. But I fail to see why, given the technological ability of pushing the button for you for security releases, we’d get almost all the way there then just add a checkbox. That’s a cop-out.

    Regular, predictable releases — something 3.7, 3.8, and features-as-plugins are trying to better establish — is really important to our future, and if we can take the update button out of users’ hands for minor releases, it means we can get away with more frequent minor releases, and then users only need to worry about major ones. They’re already opting in by updating to WordPress 3.7 — all we’re trying to do is make sure their install of 3.7 is as stable and secure as possible.

    Astute readers will notice I’ve by now cited every section of our core philosophies. As a reward, here’s a relevant quote from one of my favorite TV shows, The West Wing:

    If you think that I’m going to miss even one opportunity to pick up half-a-knot boat speed, you’re absolutely out of your mind. When it costs us nothing, when we give up nothing?! You’re out of your mind.

    Here’s the clip, by the way (only 1:28 and well worth it).

    If we give up nothing, we’d be out of our mind for not ensuring that as many WordPress installs as possible are stable and secure. We owe that to our users and to the web.

    Create forum topic from comment

  19. @Andrew Nacin – I 100% agree. In fact, I’ve been running and auto-update plugin for a while that does not only WP updates but also plugin updates automatically. Love it.

    For certain users, yes, have a hook or flag that can be changed inside the config files — but don’t cop-out to a user-facing checkbox.

    Having said all this, the fact that plugins could potentially break during an auto-update indicates that it might be nice if auto-updates could be configured to work with some sort of snapshot backup plugin (existing or new), in the event that something DOES happen.

    Still, plugin standards have improved a bunch in the last few years, to the point that I can’t remember the last time something broke on an update. Maybe including a method to disable all plugins before updating, then re-enable (and not re-enable if something pops up with an error?) could work.

    Obviously the worst-case scenario for a WordPress update gone awry is that a user can’t login to their Dashboard b/c of an autoupdate — something that isn’t really possible if Chrome or Firefox updates break an extension.

    Create forum topic from comment

  20. Hey @Christina – The only thing have to fear in one of these updates is ourselves, not plugins. There’s probably no one more terrified of this breaking a site than me and Dion Hulse, and so we’re going to make sure it’s not possible for your site to break. We’re only talking about minor releases, which are reserved for security issues and major regressions. If a plugin is compatible with 3.7, it’s going to be compatible with 3.7.1, 3.7.2, 3.7.3, etc. We won’t start updating you to 3.8.1 if you’re running 3.7, only within the major release branch you’re running.

    So our primary worry — an update going wrong — will never have to do with a plugin. It’ll have to do with our failure to verify that files were fully copied over and properly in place. Incremental updates we introduced a few years ago (if you update from 3.7 to 3.7.1, WordPress only downloads changed files) already greatly improved the safety of updating to a minor release. The main challenge of 3.7 isn’t pushing the update button ourselves; it’s making sure the update process is as stable as possible (as outlined in the task list).

    Create forum topic from comment

  21. This is one of the best examples I’ve seen to date of where users (end users) should be considered first. 99% of the clients I take on run old (sometimes ancient!) versions of WordPress and are afraid to upgrade because they think something might break.

    None of them want to worry about upgrades. None of them will opt out, nor would want to opt out, nor have any clue how to go about opting out. They just want things to work in as worry-free a manner as possible.

    (Possibly related?)Side note: in years of WordPress use, I’ve clicked the upgrade button literally hundreds of times on all kinds of different sites and have had no (zero) bad things happen. Not that WordPress is infallible, but upgrades are extremely stable.

    This seems to be a completely obvious win for the illustrators, photographers, archivists, home cooks, and all other types of clients that I have.

    Create forum topic from comment

  22. What concerns me about auto-upgrades is data loss. If my browser completely fails at an auto-upgrade all I have to do is reinstall it. A lot of my Chrome data is saved in the cloud. The local browser data could be lost and no none would really care too much.

    If my website auto-upgrades and by some freak accident or rogue code that executes on upgrade that somehow wipes my database or deletes my plugins I’m screwed.

    What I’d like to see coupled with auto-upgrades are auto-backups. The logistics of such a thing are painful to think about, but without a way to recover from a forced upgrade I think upgrades need to be opt-in.

    Create forum topic from comment

  23. I just realised from Nacin’s comment above that I was wrong. There should be no opt-in on this. I was basing my opinion on it being for major releases, not the incremental ones. I see no reason those incremental updates could/should break anything, so the opt-in should not be necessary.

    I think in future that the major releases should be added to the auto-updates and at that point, an opt-in system would be necessary IMO. But that is a debate for another time.

    Create forum topic from comment

  25. @Andrew Nacin – You’re exactly right, of course. And thanks for the reminder that this is for minor releases — like Ryan, my mind immediately went to the holy grail – major releases.

    As I said, I’m using an Automatic Updater plugin now (and have been for quite some time) and I love it. For minor releases especially, I think this is great. I do look forward to the day when even major releases can out of the box be automatic.

    Create forum topic from comment

  26. As a managed wordpress hosting provider, I am very excited and am in full support of this.

    Do I anticipate support/questions/issues? Yes.. But I also anticipate fixes and answers.
    Because the room for error is large on the first time, doesn’t mean it’s worth it.

    I don’t see any issue this will create that a hosting company would not already be prepared for

    Just my $0.02

    Create forum topic from comment

  27. I fully support automatic updates for minor releases, without any “opt-in”, not even for existing sites. This has been my view for years. Because:

    * Minor releases are mostly security related, and fixing some edge cases that broke in the major release

    * I firmly believe this is the interest of he vast majority of users, with old and new sites. Having them to “opt in” makes the whole thing not worth it. It would be as to say that there is a danger in this option. Even if WordPress “recommends” it, they may beleive not opting in is still the “safest” choice. That would be “options, not decisions” at it’s worst

    * WordPress will better ensure the integrity of the downloaded updates.

    * WordPress releases, minor and major, are extremely stable and extremely (too?) backwards compatible. I have been running lot of sites for 9 years now, and I can’t remember one single plugin that broke completely because of upgrading WordPress (may have forgot things that happened in 2004-2006). What I remember is a (very badly coded) plugin that broke, and slightly corrupted a site, because the host silently upgraded PHP, back in 2008.

    * It will be possible to “opt out” of the automatic upgrades through a constant. That’s all we need no know, as developers. Plugins that sets this will be there before 3.7.1 is out.

    * I have installed and used the Automatic Updater plugin on all my client sites now for a couple of months and it’s just amazing

    If WordPress later wants to automatically upgrade even to the next major release without using “opt in”, I will also support that. When it comes to plugins and themes, some day, I will recommend to have a end user “opt out” for each individual plugin and the active theme, as long as the plugin/theme author hasn’t actively prevented a user “opt out”.

    Such individual “opt-out” possibility is the only thing I miss in the current Automatic Updater plugin.

    Create forum topic from comment

  28. NO to automatic updates. Absolutely NOT.

    A friend recently updated to WP 3.6 and it broke every single external link in his posts. Every. Single. One. Who knows why… a bad plugin most likely, but IT HAPPENED. Now I’m afraid to upgrade myself. And it’s not the first time a new major WP version causes unexpected behavior.

    I don’t care how careful you guys are. Incidents WILL happen. You DON’T go around breaking websites left and right because “you just know” that upgrading immediately is the right thing to do for everyone. At least if I update manually and something breaks, I’ll know it happened.

    The road to hell is paved with good intentions. Never force things on people. Never ever.

    Create forum topic from comment

  29. Another scenario just occurred to me. Imagine that I have WP installed on a development server and I’m, yes, developing a website. And here comes a new major version that breaks plugins I was counting on, changes default settings I was taking for granted, subtly alters the behavior of a key API function…

    At least it’s not as bad as if it happened in production. But as a developer I’d be very wary of ever using the platform again after such an incident, no matter how much I like it and even depend on it.

    Create forum topic from comment

  30. Opt-out should be indeed possible to people who wish to do it themselves (for example on heavily customized installations) but instead of a complete opt-out, I’d like to suggest semi-opt-out, which won’t do any automated updates, but will notify the site administrators of an available update with a button directly to the upgrades page on wp-admin.

    Create forum topic from comment

  31. Definitely NO automatic updates.

    With some of the sites that I look after WordPress updates have managed to break some on upgrade. Some of the simpler sites could probably cope with this. With the number of plugins and themes now available how are they possibly going to regression test core each time before it is released. Look at all the Jquery issues that have arisen with 3.6.

    Definitely opt in and easy roll back to previous version is a requirement for me.

    Create forum topic from comment

  32. In it’s simplest form, you’re taking choice and control away from the site owner. Whether it’s “for their own good” because “we know best”, you’re still making a decision for someone else. On principle, it just feels wrong.

    Create forum topic from comment

  33. @Miroslav Glavic – I’d like to know in what reality I can go on vacation for a month? Just kidding :) However, you mention the scenario of conflicts multiple times in your post. What I think is interesting is that how would I know those conflicts exist prior to upgrading? What’s the difference between manually upgrading the site and discovering those conflicts versus the site automatically upgrading? The only difference between the two is controlling when that update process occurs.

    @david – This line of thought that unless WordPress provides an easy way to revert to the previous instance of a site in case an upgrade goes bad is very popular. I’d be willing to go down the automatic upgrade route for everything as long as I had an escape route to put things back to normal.

    @Marty Kassowitz – It’s important to stress that we are only talking about Automatic core updates for now. Adding themes and plugins would be too much for the first go around and everyone is in agreement that automatic upgrading of themes and plugins are two separate beasts.

    @Mike Otgaar –

    After the 3.5 disaster we (web support team) don’t update WordPress at all until a clients site has been thoroughly tested on an offline mirror site. We like making money, but not from bad decisions made by the good people at WP-HQ

    Shouldn’t that be something that happens as a normal process regardless of WordPress updates?

    @Andrew Nacin – If everything ends up working out as you described, then I see no reason why this wouldn’t be something everyone could get on board with. Interesting that instead of introducing UI or anything else for opting in, that the process of upgrading to 3.7 acts as the opt-in process to automatic minor upgrades. If I’m on vacation or away from a device that’s able to push the upgrade button for a very important security release, I’d much rather have that security release applied automatically. One less thing I have to worry about.

    @darrinb – So what are your thoughts on this Decisions mantra as part of the WordPress development philosophy?

    Create forum topic from comment

  34. I expect issues, I expect lots of issues but, I don’t see any other way to make progress. I hope to one day see the ability for hosting companies like ours to become authorized mirrors, to help alleviate the load on our machines/networks.

    The issues everyone is worried about are valid, but they’ll be addressed in time.

    Create forum topic from comment

  35. First off, I’m not necessarily against this idea, I’m still forming an opinion. However, I like control of my environments. My Mac lets me know when updates are available; for my apps, for the OS, iTunes, etc. My PC lets me know when Windows has updates. Hell, even Adobe lets me know when I have updates available. I think the current form WP takes of letting the Admin user know there is an update available is a familiar route, one most end-users –technical or not– understand and are used to seeing in other software they own. Sure, Chrome and Firefox do it, but how many other software applications do?

    We’re not talking about the hosted version of WordPress, where .com has complete control over the platform, hosting environment, plugins, and themes. We’re talking about self-hosted environments where the owner of the site has (and should have) control over what he/she does with it.

    I would be in favor of an opt-in on the install screen; right under the “Allow my site to appear in search engines…” Why not an “Enable automatic updates” option? That way, it’s “set it and forget it” while still allowing control. If a dev is setting the site up for a customer, they’re making the call (or at least walking the customer through a technical decision). If a shared hosting provider has a one-click install (like GoDaddy and Mediatemple), they can enable it by default, and just have it be part of their terms of service. And if you’re someone who manages your own hosting server, like myself and the last agency I worked for, you can make the call.

    One other concern/question: the security implications. Being unfamiliar with how this would implemented, I’m curious as to the security implications of a site auto-anything-ing. Once the capability to auto-update is built into core, what’s to stop a plugin developer –either maliciously or ineptly– configuring his plugin to auto-update?

    Create forum topic from comment

  37. It was problems with updating the plugins from inside the admin area that had me leery of any sort of update like this. It took me until about 18 months ago before I trusted WP’s systems enough to start clicking on the “update now” link for plugin updates… before that I always updated manually with FTP because I’d previously never had a plugin update succeed without trashing whatever site I was working on.

    I still won’t do a WP update unless it’s manuall, not even the minor ones. I simply do not trust all of the moving pieces that I know can hiccup at the wrong moment for an update a large as WordPress is (and it continues to expand in size).

    I’ve had clients click the pretty little “update now” button and break all sorts of things that they sometimes felt they didn’t need to pay me to fix. Having an update the likes of 3.5 or 3.6 done automatically, without a method to prevent it, would be disastrous, especially for people managing a lot of websites on different hosts for different clients.

    If the WP team ever puts up a survey about opt-in and/or opt-out, I’m going to be in that very large group that’s saying “Thank you, but No. Let us choose how best to update our websites ourselves.”

    Create forum topic from comment

  38. Most commenters, few exceptions, seems not to see any difference between “minor” releases and “major”. The “minor” releases are mostly security fixes. Those may open a site for attacks, once the vulnerability is made public. So the “minor” updates are more important then the “major”.

    In a “minor” release there are no API changes, no removed or deprecated functions, no arguments removed or deprecated, no db changes and no new strings.

    Automatic updates will not start rolling until there has been room for feedback from those who have manually updated. We should discuss how long time this delay should be.

    Only automatic updates for minor releases, without “opt-in”, is suggested for 3.7.

    If, and when, automatic updates is suggested for even major releases, an “opt-in” should be discussed again.

    WordPress may also release a 3.7.x update after 3.8 is released, if the 3.7 branch needs security fixes.

    Many commenters seems to think they, or their clients, will be forced to have automatic updates. Almost nothing as mandatory in WordPress. Almost everything can be changed and tweaked. By the time WordPress 3.7 is out, and long before 3.7.1, there will be plugins available to turn off automatic updates, and from day 1 any developer or somewhat skilled end user, may define a constant in wp-config.php to avoid automatic updates, but still be able to do them manually.

    So the “take away control” argument is moot.

    The focus should be what he huge majority of users will benefit from.

    So “I don’t ever want automatic updates, not my sites, not on my clients sites!” is quite ok, for whatever reason you have not to trust updates. Nobody and nothing will force you. Same thing as for the somewhat controversal admin toolbar, that was introduced some releases ago. There is no “opt-in”. But if you don’t want it, you remove it through a few lines. No big deal. No “taking away control” over the admin layout, or the site, as site owner.

    For myself, I do minor updates almost blindly on all sites, without testing. I know that if I would have to revert I would just install the previous release through FTP. If I ever came across a site that is so delicate, and relying on a security flaw, or a new edge case bug just introduced in the latest major, I would define a constant to make any update to anything not possible from inside WordPress. Until I had the time to fix the site properly.

    Create forum topic from comment

  40. I’m not a developer.
    I’m not a coder.
    I’m not a WP guru.
    I am a little guy that has about 100 client websites out there and they all work to the satisfaction of each and everyone of my clients. When I started building websites, I was even more ignorant than I am now, so about 20 of my websites have had changes made to the core files, because I didn’t know any better. Do I remember what those changes are or where I made them, not so much.

    I see people above trying to differentiate between minor and major releases. That’s nice in theory, but the real life fact is that I have pressed update in instances of either type of update and had things break. I understand when I read that “minor” updates don’t affect API’s and such, but honestly, I have had sites break from pressing update on both types of updates.

    Just standing there and telling me that I shouldn’t have a choice in the fashion in which my site components, whether WP core, theme and plugins, update is a none starter. Someone above said that “the only thing we have to fear is ourselves” is a nice soundbite, but not really rooted in reality.

    The choice must be very clear and upfront for each person to decide for each of their websites. I’m not sure how someone can make such a blanket statement such as “If a plugin is compatible with 3.7, it’s going to be compatible with 3.7.1, 3.7.2, 3.7.3, etc.”, when this is just not true. Just Google “the only thing I did was apply a “minor” upgrade and now my xyz doesn’t work any more.” We can’t all be making it up.

    On an unrelated note Jeffro, the reality above is the one that I live AND I get to take a months vacation every 8 months or so. :-)

    Create forum topic from comment

  42. I don’t want anything happening to my WordPress install without me knowing about it first. I’ve been hacked before.

    Even if I update every time it shows one is needed I want to make that choice – not WordPress. It is my install.

    I don’t care if it is for minor core updates I want to be able to decide if I update or not.

    Create forum topic from comment

  43. @Patrick Daly – This is the problem – if its automatically upgraded and crashes, there’s no backup to restore (and wordpress always advises that you backup eveything before you update, so you aren’t sure it will be safe – you can’t possibly be, because you can’t possibly have tested all the unknown hardware and system configurations its running on, never mind the combinations of flaky and incredibly complex plugins that exist (and ‘my’ special one that you’ve never seen and never will)). The Nextgen debacle should be a warning to anyone considering automatic updates of a complex and user modifiable system. As an ex-IT professional, this is one of the most stupid ideas I’ve heard.
    Fundamental – you know little about the client system, you can’t know everything about the client system, and you won’t be able to do anything to help the hapless user recover from a disaster caused by an unwanted, untested update. Or are people not supposed to use WordPress for any commercially important system?

    Create forum topic from comment

  44. @Felix – That sucks that you are so against automatic upgrades but it only takes one bad experience to fear going through that process again, even if it wasn’t directly the fault of WordPress core. However, what if you didn’t do an auto upgrade and manually upgraded the site? Wouldn’t the problem surface anyways? Better to be aware of it sooner rather than later?

    Create forum topic from comment

  45. Just to review because this has been such an interesting discussion. There are users who don’t like the idea of automatic upgrading anything, there are those who are perfectly fine with automatic upgrades for minor releases but not for major releases, and there are those who are afraid to upgrade without some sort of fallback such as a revision or restore point. The discussion above has mixed in plugins, themes, and core when in reality, this is all about WordPress core specifically, minor releases. Auto updates for themes and plugins are not on the radar at this time.

    The plan is to deliver auto upgrades for minor releases but enable constants in the WP Config file to manipulate their behavior such as disabling auto updates or doing both minor and major releases. As someone mentioned, either before or shortly after 3.7 is released, there will be a plugin created by someone which enable the common lay person to change the behavior of automatic updates.

    I’m still ok with doing automatic minor release updates for my own WordPress site and as far as restore points go, are we not supposed to be backing up anyways prior to messing around with core?

    Create forum topic from comment

  46. @Jeffro – If I do an update, I make a backup first (which happens to be what WordPress warns you to do anyway). If it goes wrong, I can restore the backup. If WordPress just does an update of its own volition, there may not be a current backup, and even if there is, it won’t be restored until I discover WordPress has trashed my site.

    and wrt your comment “I’m still ok with doing automatic minor release updates for my own WordPress site and as far as restore points go, are we not supposed to be backing up anyways prior to messing around with core?” The answer is of course yes, but allowing wordpress to mess around without our permission means that upgrades will be made without a backup, and, worse, without the site owner even knowing about it.

    Create forum topic from comment

  47. @mike finley – I get where you’re coming from. Certainly there will be a welcome pointer or it will be mentioned in the 3.7 welcome screen. It would be foolish not to put information there about auto updates. Unfortunately, there will still be a bunch of people who will claim they didn’t read or hear anything about auto updates and they will be pretty upset that WordPress broke their site, even if it’s a plugins fault. However, I plan on writing about this again once 3.7 is released and I’ll be sure to link people to any Automatic Upgrade plugin manager plugin that exists at the time for people that more control over how it works.

    Create forum topic from comment

  48. However, what if you didn’t do an auto upgrade and manually upgraded the site? Wouldn’t the problem surface anyways? Better to be aware of it sooner rather than later?

    That’s exactly my point. If I do a manual upgrade and it breaks, I’ll know right away. If WP upgrades itself overnight, I won’t know until morning. And then I won’t even be certain it was from the upgrade. What if my hosting provider also broke something within the same time interval? Simultaneous issues happen a LOT, and they make it very hard to debug as you chase the entirely wrong lead for hours or days.

    Create forum topic from comment

  50. @mike finley –
    The site owner will know about it. There will be an email sent to the site owner/admin.

    The risk that a minor update breaks anything is very small. The policy is just to fix serious vulnerabilities and severe regression issues of the main release. Latest versions of external libraries, like jQuery and the like, will not be included in minor releases.

    Finally, automatic updates will only take place about 12 hours after anyone will have had the opportunity to do a manual upgrade, giving time to stop the automatic update if anything breaks after all.

    Unattended sites getting hacked due to publicized vulnerabilities is a much bigger problem. This great enhancement has come to combat this.

    Take a look at http://wordpress.org/plugins/update-control/ and live more safe/dangerously.

    Create forum topic from comment

  51. Finally, automatic updates will only take place about 12 hours after anyone will have had the opportunity to do a manual upgrade, giving time to stop the automatic update if anything breaks after all.

    So that’ll be the twelve hours between packing up in the evening to coming back the following morning then?

    Create forum topic from comment

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

    Create forum topic from comment

  53. @Aron –
    I’m not saying, no one I’ve seen, are saying it can’t break. It can, but it still unlikely and a very few sites affected.

    I this case, automatic update would have been cancelled, because the problem some got was spotted within the delay time. How many hours, days or weeks (?) should pass after a security release before automatic updates are pushed? That’s the question.

    The point is that this quite rare cases are outweighed hundreds of times with all the almost abandoned, the static sites, that may be in jeopardy if not ever updated.

    To me such automatic updates are as obvious as it is mandatory for a plane to be retrofitted or repaired when a similar plane has had a serious incident, and the cause of that is the plane’s technical state. You don’t wait until the captain or the airline feels the plane needs to be repaired. And, of course, the repair may introduce unforeseen problems.

    There are a lot of software having automatic updates, and this is great success in combating publicly known vulnerabilities being exploited.We are on the internet, there is not only the cause of the sites owner, but the global, online public.

    It’s exactly “the mainstream” that will benefit from this. Hacked sites, he spread of malware and fraud through such sites is an alerted disaster. WordPress not doing this, at least trying it’s best for now, would be a todays “McDonnel Douglas” of 1973 (DC10 scandal).

    Create forum topic from comment

  55. @Knut Sparhell –
    I agree, I find myself logging into clients websites from years ago that we don’t have service contracts with or host just to see if they upgrade. I always find outdated WordPress sites. I end up upgrading them. I just hate to see the update nag and think that the site is asking to get compromised. As long as the upgrade process has a fail safe system and automatically backs up before upgrading It would be fine. Chrome for example upgrades all the time. Especially Chrome Canary but if anything goes wrong as it did for me a few times. I can just delete the app and remove some chrome files in my ~Library then reinstall and all would be well since all data is stored in the NSA cloud. Maybe an app store or something to test before release. Thats another thread though…

    Create forum topic from comment

  56. To me such automatic updates are as obvious as it is mandatory for a plane to be retrofitted or repaired when a similar plane has had a serious incident, and the cause of that is the plane’s technical state. You don’t wait until the captain or the airline feels the plane needs to be repaired. And, of course, the repair may introduce unforeseen problems.

    poor analogy – two blogs aren’t as similar as two planes of the same make and model. A site running on IIS isn’t going to have the same characteristics or security holes as one running on Apache with a different version of PHP and with different plugins – especially if one of them is running multi-site. Its the huge diversity of platform details that make automated updates a risk.

    Create forum topic from comment

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.