How to Configure Automatic Core Updates for WordPress 3.7

So, how does this work?Today following the release of WordPress 3.7 many users are wondering where the settings page is to configure these options. The answer is that there is no settings page in the WordPress admin. If you upgrade to WordPress 3.7, the default behavior is that you’ll be automatically upgraded for security and minor releases.

The fact that it’s security and minor releases only is a very important distinction here. These generally do not break anyone’s website, plugin or themes. If you’re using a plugin that gets broken due to a security release, then that raises a red flag and a few questions about how that plugin is interacting with the WordPress core.

If you want to make changes to WordPress default behavior of keeping your site current with security/minor releases, you will need to edit your wp-config.php file.

I asked Andrew Nacin if there is a plan to expose the core update configuration options to the UI in the future. He replied that there is “no good reason for an opt-out UI now, but as we grow more confident, I imagine an opt-in UI for major versions could be next.” So maybe this is around the corner, but for now, read on to learn how to configure your updates.

3 Basic Options for Core Updates in WordPress 3.7

Let’s simplify things here. You basically have three options for WordPress core updates:

1. Update the core for minor versions (on by default):

If you’re running WordPress 3.7, there’s nothing you need to do to turn this on. You’ll be automatically updated for security and minor releases. Here’s what it would look like in wp-config.php:

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

2. Disable all core updates:

If you’re uncomfortable with WordPress keeping your site current with minor releases and security updates, here’s how you turn it off. Add this to your wp-config.php file:

define( 'WP_AUTO_UPDATE_CORE', false );

However, I would encourage you to read this definitive guide from Nacin before turning off core updates completely.

3. Get all updates, including development, major and minor releases:

This is the cowboy option that is probably more likely something you’d want to enable on a personal blog. If you turn this on in wp-config.php, you’ll be automatically updated for every release that WordPress puts out:

define( 'WP_AUTO_UPDATE_CORE', true );

You can also apply all of the above via new filters added in WordPress 3.7, as outlined in the codex article on Configuring Automatic Background Updates. Filters are also available for plugin, theme and translation updates should you want to add those in the mix, too.

If you’re scratching your head and trying to get your brain around all of these options, wondering what to do, then just leave the default options in place and don’t mess with it. WordPress strongly discourages disabling the automatic security updates. These updates have been heavily tested and are quite safe. Getting hacked because you didn’t want to take security updates would be really lame. The best option is to leave security updates in place.

I will take your advice and not be “lame”;) disabling the security and minor releases.
A question. The Relevanssi plugin broke when updating to 3.7 . Does this mean, that it “raises a red flag and a few questions about how that plugin is interacting with the WordPress core”?

@Steve Moss – I know a ton of people use this plugin so you may want to post about it on their support forums, as others already have. If you are concerned about it, there are other options, such as Swiftype you might look into.

@Steve Moss – One of the improvements to WP 3.7 is improved search results and so that is likely a conflict with the Relevanssi plugin and you may want to disable it until the plugin author can update his plugin to not conflict with 3.7.

One thing I’d like to see is the ability to update core on milestone releases, such as Beta-1, Beta-2, RC-1, etc. So, essentially: core would stay at the most recent major/minor version, until a beta or RC is tagged, then update to that milestone. All other nightlies/dev updates are ignored.

I would use such a scheme for keeping development installs (such as what I use for Theme/Plugin development) up-to-date, and to perform beta-testing of Themes/Plugins concurrently with core.

@Wilson – Yes you should be able to get translations faster now. WordPress 3.7 now has the ability to install the right translations files and automatically keep them current in the background as well.

It will be a cold day in heck when I allow machines to push changes to production servers with 0 testing on a stage machine. I’m not waking up in the morning to an east coast client telling me their B2B ordering system is down and “what the heck id I do to break it”. “Oh, sorry but what I didn’t tell you is that I outsourced security and patching maintenance to a bunch of magic elves. They said everything would be well tested first.” doesn’t make a good answer.

Maybe it is because I came out of the entertainment and online games industries but I believe it would be obscenely irresponsible.

@mike finley – I was thinking about this earlier today. A 3.7.1 release can either be a minor release, security release, or both. Over the years, we have described them as two different updates but both up the version number the same. You can’t call it one or the other because some of the minor upgrades are just typical maintenance releases. This is something I’d love to hear Andrew Nacin lend his wisdom to.

@mike finley – Correct, it’s all minor releases. 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.

Before wandering by to see what people’s ideas and opinions were I had already disabled it in the on all of my server configs, doing it now though I had only installed the update on my multi purpose test machine yet and will not be putting it onto any of the staging machines until their daily checkup in the evening (we do continuous build, but things that require human intervention get saved for the last overview of the day). I will probably then let the stage machines sit and marinate over the weekend, and if we like the look of things on Monday, and stuff we wrote ourselves still pass PHPUnit testing (and a quick sniff with a code smells detector doesn’t think 3.7 is fatally flawed which would surprise the heck out of me if it did), Tuesday morning some people will get a memo mentioning the latest changes and features and reminding them of my personal cell number. I won’t upgrade more than one or two a day so that there will be minimal risk I’ll be having to have one client hold for another’s call, or worse be letting anyone go straight to voice-mail!

Hopefully that way my elves and I will stay on everyone’s christmas card list ;)

Looks nice and shiny by the way!

@Andrew Nacin Thanks for the definitive guide link. I am glad I checked to see if anyone had posted something interesting while I had been writing. I almost missed it!

Lol, i have bulletproof security running and it has the option to restore any changes in files in the root. It also write protects those files. So this is their way to prevent the website from being hacked. That will create a big mess after wordpress updates.

I will setup a test server to see what the outcome of that will be. This could become very funny.

It’s not a big hassle to install the plugin and happily use the latest development releases(of course you can also use version control to directly update your core files with Git or SVN, but that’s a different story).

I believe that this specific plugin should not be merged with core – if you’re a developer and want to stay up to date with the latest WordPress builds – then you install the plugin. Normal users should not have that option out-of-the-box in my opinion.

@Chip Bennett – Nice idea for sure. I don’t think we’d need to actually introduce a new value for that. Running a development version is enough to receive auto-updates to that branch. Unfortunately, that means you automatically “skip” to the next branch (so you’d go directly from 3.7-RC2-golden to 3.8-alpha). I actually prefer that, because it means people continue to test trunk, rather than us losing our body of testers each release. What actually should happen is the beta tester plugin should give you a proper choice: Do you want to just test 3.7, or do you always want to be on the bleeding edge? This is something we intend to revisit in 3.8.

Actually – it’s possible to stay updated with beta and nightly builds. It doesn’t come with core – instead you have to install the “WordPress Beta Tester” plugin

Yeah, I’ve been using Beta Tester for a long time now. :)

Beta Tester basically lets you choose between point releases and bleeding-edge nightlies. One would think that a Plugin named Beta Tester would include an option to update to release milestones such as Beta and RC.

Its functionality is essentially part of core now, with the available filters. But both core and the Beta Tester Plugin miss a key demographic: Theme and Plugin developers who need/want to start testing for compatibility at beta, and not before.

I don’t think we’d need to actually introduce a new value for that. Running a development version is enough to receive auto-updates to that branch. Unfortunately, that means you automatically “skip” to the next branch (so you’d go directly from 3.7-RC2-golden to 3.8-alpha). I actually prefer that, because it means people continue to test trunk, rather than us losing our body of testers each release.

I don’t mind being a core bleeding-edge tester. But I’m a small-time developer, and even I have a dozen Plugins, plus a Theme to support. I don’t have time to try to monitor them throughout the development cycle. APIs change, things break, and although nightlies tend to be generally stable, they can cause a lot of unnecessary re-work for Theme/Plugin developers trying to keep their code compatible. Milestone releases – betas and release candidates – should have APIs stable enough that it makes sense for Theme/Plugin developers to make compatibility changes at that point.

It is standard practice (in any software project) for extension developers to begin compatibility testing at the beta stage. IIRC, it is even (or used to be) MO for the beta and RC release updates from make/core include a request for Plugin/Theme developers to begin testing their code against the release. It would be awesome if the core automatic update feature could account for that.

(And I would go with a filter rather than a wp-config constant.)

I do hope this decision is revisited in 3.8, because I think we’re missing a slam-dunk opportunity to facilitate more Theme/Plugin developers to begin compatibility testing at release milestones, without having to stay on bleeding-edge nightlies.

By the way: is there any documentation on how the various transients work together, including how often WordPress checks for updates, whether or not api.wordpress.org sends the update, and when/how often the update routine executes?

Right now, I’m sitting here with an update_core object that has had the 3.7.1 update (since last evening sometime), but the automatic update isn’t firing. That’s being controlled by the delayed rollout, but I can’t seem to track down how all that works together.

@Chip Bennett – The 3.7.1 update offer you see in the transient is for manual updates only. The auto update is a separate offer that is only being provided to about 75% of installs at the moment. It shows as a “response” of “autoupdate” instead of “upgrade”. When your site receives the instructions, you’ll end up with not one but two offers in the transient. See find_core_auto_update() and get_core_updates() (both in wp-admin/includes/update.php) for more.

I just got an e-mail from WP that says “Howdy! Your site at http://GHotos.com has been updated automatically to WordPress 3.7.1.”

I had upgraded the site to 3.7, did not modify the config file and the config file does not have the line of code in it.

The only odd thing is the update message is from right around the time that I logged in to check and see if it had updated. It had not and asked me to (up at the top of the screen) and I ignored it. I’m not sure if logging in possibly triggered it to update. (It’s an interesting coincidence if it didn’t).

@Gary LaPointe – No. Logging in did not trigger the update. It took a lot of restraint but I saw the upgrade message for 3.7.1 for hours on end before I actually received the email tonight, letting me know WPTavern was upgraded automatically to 3.7.1 with no problems.

@Jeffro, @Gary LaPointe – It’s possible that logging in did trigger the update. The WordPress cron system is able to fire off scheduled tasks only when a site has been visited. It’s possible that your visit triggered the update. This is pretty rare, but certainly possible, and even something we even considered.

Great tips. That works for WP 3.7.1 as well. I have another issue. One of my sites at http://vietnammotorcyclemotorbiketours.com can’t automatically detect available update version of plugins. I set up 9 sites with the same settings and other 8 sites can display updates for plugins when available. Anyone has any idea how to fix this?