Automatic Core Updates

[pento]

It's time to think about automatic updates for WordPress Core. Plugins and Themes are a totally different ball game, so it's probably best to leave them for the moment. Currently, I'm thinking it would be a good idea to release this in stages (some of which may be combined, just spelling them out):

• SVN updates in trunk installs
• SVN updates in branch installs
• Opt-in updates in stable installs
• Opt-out updates in fresh installs
• Opt-out updates in all installs
• Remove option for opting out

I'd like to see SVN updates go into 3.6 early, so we can quickly get a good idea of compatibility issues that we're likely to run into when we get to beta.

Finally, are there any features we should be looking at adding to the upgrader for this? More sanity checking, notifications, other?

Replying to pento:

Finally, are there any features we should be looking at adding to the upgrader for this? More sanity checking, notifications, other?

Probably three-fold:

• Sanity checking via file hashing (confirming that files actually got copied over)
• Sanity checking through some other means, like a parallel install
• Notifications

I've never really thought heavily about SVN updates. As a developer, having an SVN site update automatically is weird and probably not desirable. If you managed to do a checkout, you can set up a cron to update it.

The first step is probably opt-out (or opt-in, if we are chicken) updates for security and maintenance releases. The next step is probably an update from major-to-major after the .1 drops.

Warning you now, this Trac ticket is likely to get out of hand, quickly. Trac is more about implementation, not planning out potential roadmaps. (Though I applaud your initiative and can't wait to see you build it.) Summaries of the extensive Updates discussion from the community summit should probably be published (if it hasn't been already), and then this should be taken to a P2 thread.

Replying to nacin:

Though I applaud your initiative and can't wait to see you build it.

He has: ​http://wordpress.org/extend/plugins/automatic-updater/

At Bluehost, we've been researching this for a few months now (and yes, we have tested your plugin a bit with a lot of success - but it certainly has it's limitations right now).

Anyway, our biggest problem has very little to do with how automatic upgrades are implemented (whether it's in core, or in an mu-plugin we provide ourselves). It's that eventually, all installed plugins and themes will break themselves, core, or both upon a major upgrade of WordPress core in an undetectable way; just backwards incompatibility issues. I've run the statistics as best as I can without actually using our customers as test subjects, and I've even ​written a proposal for one possible solution to this (which also contains some of those stats).

I don't understand why WordPress core needs this. Seems like a small percentage will use this and this feels like an item that shows how WordPress is all about feature creeping instead of being a robust platform.

In my opinion there isn't a good way and still have an easy to use system. Maybe when we add a lot of black magic to WordPress but for me that just feels wrong to do so.

Related: #15738

From what I have seen(in the past working with clients), most WordPress installs need to be upgraded. Why would we not want to do this automatically, assuming we can provide the right experience? The problem is the experience a user will have when something does go wrong, that is why there needs to be checks. IMO auto upgrades are about security not new features. If we can keep plugins/themes updated as well, I think the amount of hacked sites we see will go down. Replacing the experience of "My site was hacked" with "My site is up to date automatically?". I think we could live with that. Explaining to them how it stayed up to date vs explaining how to fix a hacked install. Will this fix everything? No. But it will help.

If I'm geting this right, #18200 (birth of the language pack) is probably somewhat related, too.

Replying to mikehansenme:

IMO auto upgrades are about security not new features. If we can keep plugins/themes updated as well, I think the amount of hacked sites we see will go down.

I would tend to agree. Auto update to major versions is something I can see breaking sites, but of course if you can disable auto-update for major versions via a hook then I don't think it will be a problem. If there's significant custom development on a site that might break then the site builder has the skills to add the "no-major-version-update" hook as well.

For plugins I think that would require version numbers to actually matter, and right now there's no well-known advice provided for plugin developers on how to do versioning "right". Maybe WordPress plugins could adoption ​Semantic Versioning as the best practice and then opt-in via a header line "Auto Update: Yes" for automatic versioning?

If we do auto-upgrade, there has to be an opt-out method (an option define(AUTO_UPGRADE, false); at the very least) so we can regression test plugins and hacks. While auto-upgrades, in general, are awesome ideas for the small-fry sites (casual bloggers with limited tech chops and few plugins), it becomes problematic when you introduce plugins like BuddyPress, which often must be upgraded with WP in order to work to it's fullest potential (or work at all, and this is not a dig on BP, it's just that it's very much tied in to core - nature of the beast).

Auto-upgrading minor releases strikes me as a better first-step. Kind of like the hotfix, only with less of a 'You still need to upgrade the plugin' need. That would help security a lot, and make it possible for in a case where we have, say, the need for a fix in v 3.5.3 the day before we want to drop 3.6 to cover both. A silent auto-up of a couple files (now that we have the incremental updates yay!) would be unnoticed by most users, and CYA till they can do the major up. From a support persective, the minor upgrades aren't 100% painless, but they're usually quiet enough that I wouldn't envision massive headaches for this.

I am NOT proposing we support older versions, just putting a use-case out there. I recall we've had cases where we had to upgrade a previous release due to the timing of the major release, and this could help us out there and make it less of a headache.

I would be ok with 2 options to enable/disable minor and major versions of automatic updates as a starting point. I do think it would help get the ball rolling by reducing concerns some users may have.

Definitely in agreement that it seems appropriate to start from the minor and security upgrades for a first pass.

From what I've seen, we have generally very low volumes of support (to none) when we run minor upgrades. I'm sure that if these became automated in core, everyone committing would be even more careful about what goes in them.

The biggest security concerns come from plugins, so it'd be good to have a solution that keeps them in mind for the future (perhaps a tag to let plugin authors specify an upgrade as a security update, which was talked about at the summit).

As far as major release auto-upgrades go, I'm a fan of moving forward on them, but with this as a second or third step (likely at least two major releases forward from now).
Plugins and themes need to be, at the very least, taken into account if we want to do them properly. As it's been talked about above, it'll be important to avoid auto-upgrades if it's going to cause a fatal error. This situation is the one we see most often when we auto-upgrade users, and generally speaking it's a problem because the users haven't kept their plugins up to date before the core auto-upgrade takes effect.