Different Ways to Disable Auto Updates in Wordpress

I have to 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

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 );

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 wordpress 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 likeDISALLOW_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 withDISALLOW_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:

 /* @param bool $send Whether to send the email. Default true. * @param string $type The type of email to send. * Can be one of 'success', 'fail', 'critical'. * @param object $core_update The update offer that was attempted. * @param 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.