How to Configure Automatic Core Updates for WordPress 3.7

So, how does this work?
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.

53

53 responses to “How to Configure Automatic Core Updates for WordPress 3.7”

  1. Can we have accurate reporting please?

    The fact that it’s security releases only is a very important distinction here

    would be an important distinction, but its not true. Its all minor updates, not just security updates. There is no way to select ‘security releases only’.

  2. Thank you Sarah for the info.

    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

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

    Perhaps:

    define( 'WP_AUTO_UPDATE_CORE', 'milestone' );

    or:

    define( 'WP_AUTO_UPDATE_CORE', 'prerelease' );

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

    Kurt Flint
    Sometimes Consultant
    (and CTO of the stock watch index group)

  5. @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.

  6. […] Eine Aktivierung von automatischen Updates für alle Versionssprünge ist zwar auch möglich, allerdings bewusst standardmäßig nicht aktiviert. Bei großen Updates kann es zu Inkompatibilitäten mit Plugins und Themes kommen, die man möglicherweise erst spät bemerkt, wenn WordPress sich unbemerkt aktualisiert. Man sollte wie immer “manuell” updaten, wenn man die Kompatibilität geprüft und ein Backup gemacht hat. Eine Deaktivierung aller automatischen Updates ist übrigens auch möglich. Weitere Infos: How to Configure Automatic Core Updates for WordPress 3.7 […]

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

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

  9. Hi Sarah,

    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.

    Best regards,
    Neo

  10. So I’m still a little confused on the what is considered “minor”.

    Clearly minor is not getting me the development releases.
    Minor will get me 3.7.1 (right?)

    But will minor updates get me 3.8? Is a 0.1 upgrade “minor”?

    I’d think a jump from 3.x to 4.0 would be considered major…?

    Gary

  11. When you say “on by default” makes me think that even if

    define( ‘WP_AUTO_UPDATE_CORE’, ‘minor’ );

    isn’t in my wp-config.php file, it’ll still update automagically. Correct?

    Or do you just mean that in new installations that line of code will be in new config.php files?

    I just updated one of my sites and see that like of code is not in the wp-config.php file.

    Thanks!
    Gary

  12. @Gary LaPointe

    So I’m still a little confused on the what is considered “minor”.

    Clearly minor is not getting me the development releases.
    Minor will get me 3.7.1 (right?)

    But will minor updates get me 3.8? Is a 0.1 upgrade “minor”?

    I’d think a jump from 3.x to 4.0 would be considered major…?

    Saying that a jump from 3.x to 4.0 is major would be a version schema where X is a major update, and X.Y is a minor update.

    That’s not how versioning works in WordPress. In WordPress:

    X: no such version
    X.Y: major
    X.Y.Z: minor

    So, there is no such thing as WordPress Version 3, nor will there ever be anything such as WordPress Version 4.

    Major WordPress versions are 3.0, 3.1, 3.2, 3.3, 3.4, 3.5, 3.6, 3.7, and soon: 3.8.

    Minor versions are 3.6.1, 3.7.1, etc.

    And here’s the kicker: versions 2.9, 3.0, and 3.1 are all equally major versions. Likewise, versions 3.9, 4.0, and 4.1 will all be equally major versions.

    This is a common point of confusion – and, I suspect, perhaps a contributor to some people not updating from version X.0 to version X.1 or later.

  13. @Gary LaPointe

    I just updated one of my sites and see that like of code is not in the wp-config.php file.

    WordPress neither creates on install nor overwrites on update the wp-config.php file.

    The easiest way to control the settings would probably be via Plugin. There are already a few in the Plugin directory that will expose UI to configure the various settings.

  14. […] The same concerns that were brought up when automatic updates were announced are still being voiced. The biggest concern users have is not being able to easily go back to a working version of WordPress should something break. At the crux of this particular concern is that automatic updates prevent people from creating backups immediately before the update process. The update process has failsafe after failsafe to prevent catastrophes from happening but there is no guarantee. By default in WordPress 3.7 and above, the only updates that will happen automatically are minor and security releases. Although they have different names, these releases can sometimes be the same thing. Andrew Nacin explained the differences. […]

  15. @Chip Bennett – 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 – http://wordpress.org/plugins/wordpress-beta-tester/ .

    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.

  16. Thank you for the blog post.

    I am working with a business owner and it seems that she hasn’t done ANY updates since 3.0.5 … I know to back everything up… but are there any concerns about going from 3.0 directly to 3.7.1?

    Thanks
    Bridget

  17. @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.

  18. @Nikola Nikolov

    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.

    @Andrew Nacin

    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.

  19. @Andrew Nacin

    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.

  20. @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.

  21. @Gary LaPointe

    But NOT having the line of the code in the file mean that it’s going to do the default function, right? Which would to do be minor upgrades?

    The word “default” implies it’s going to happen regardless (of the line of code).

    Not necessarily. There are two different ways to control the automatic update functionality:

    1. Defining constants in wp-config.php
    2. Filters

    The available Plugins use the filter method, rather than the wp-config.php constant method. Both are equally effective.

  22. 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).

Newsletter

Subscribe Via Email

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