Automatic background WordPress updates were introduced in versión 3.7 and since then, this module has been maintaining your installation updated and ready for working however in some cases, you don’t desire that your WordPress installation changes without your permission. Perhaps for compatibility with a special developement addition, perhaps for some non updated but critical plugin or any other reason you do need to control manually the WordPress Updates. If this is your case then go ahead but rather it is much better to leave the maintenance module quiet.
As the official documentation explains about the Automatic Background Update Module, this module has 4 different Types of working.
- Core updates
- Plugin updates
- Theme updates
- Translation file updates
And in addition, three more approaches for disabling, changing and controlling respectively:
- All Types in one operation, and
- The kind of updating allowed specifically for the WordPress core elements, and
- Which sub-module should (or not) be updated in each of types.
Despite of all of these former processes work apparently like an unique module, all of them are completely independent and you can perfectly change the behaviour of one without affecting the others. For example, you could decide don’t allow just the updating of the themes, or of the translations, etc. and to do this you must just change one of the former filters (or two, or whatever number) that control each one of Updating Processes. Well, step by step.
Blocking globally Automatic Background Updates. Main filter.
For controlling globally if WordPress is allowed for updating your installation or not, you have to change the first filter called automatic_updater_disabled that reveices just one boolean parameter that starts (TRUE) or stops (FALSE) complete and globally this module. If you add a little code like this to your function.php file.
<?php
function disallow_WP_updates ( $allow ) {
return (boolean) ( ( $allow ) ? !$allow : $allow );
}
add_filter ( 'automatic_updater_disabled', 'disallow_WP_updates', 10, 1 );
?>
From this moment, all the Automatic Background Updates will be stopped… But, please, don’t use this first level if you don’t actually need to freeze your WordPress Installation in time. Well, I admit that sometimes, for example in a very critical production installation, it’s necessary to use this filter but, between you and me, in most cases there is always a solution less radical (and more intelligent) that to block to WordPress in that way.
Blocking individually each one of Update Types. Type filters.
For stopping or starting each one of four Update Types (core, plugin, theme and translation), you have to configure these filters: auto_update_core for core elements, auto_update_plugin for plugins, auto_update_theme for Themes and auto_update_translation for translations. For example, you can use a function like this next for blocking the translation update Type.
<?php
function disallow_translations ( $update, $item ) {
$update = FALSE;
return $update;
}
add_filter ( 'auto_update_translation', 'disallow_translations', 10, 2 );
?>
In that case we work with the first parameter received for the filter and we return just a boolean result. The updating of plugin is blocked.
Controlling the modes of working of the core update Type. Mode filters.
In case of Core update Type, in addition of the auto_update_core filter, there are three more filters that permit you to control what kind of changes do you want allow: all changes, only minor changes or even, to allow developement changes, respectively, allow_major_auto_core_updates, allow_minor_auto_core_updates and allow_dev_auto_core_updates.
For example, if you write a function like this next, you don’t allow minor changes.
<?php
function disallow_minor_changes ( $allow ) {
return (boolean) ( ( $allow ) ? !$allow : $allow );
}
add_filter ( 'allow_minor_auto_core_updates', 'disallow_minor_changes', 10, 1 );
?>
However, each one of these former three filters only works in certain contexts and in other contexts, it is useless. Now, we’ll seeing this point in detail that depends on the kind of WordPress version change. The number of the WordPress version has three parts X.Y.Z –for example WordPress 4.1.2– so that, depending on what part of version number changes, we’ll be in an update mode or in another.
If the changes are in the X or Y parts of version number, ie, for example we have the 4.1.0 version and the proposed version for updating is the 4.2.0, then we are talking about a major version update and the active filter will be allow_major_auto_core_updates, the minor filter haven’t got any effect. For the contrary, if the part that changes is Z, then we’re talking about a minor update and in consequence, the active filter will be allow_minor_auto_core_updates, ie, for example we have the 4.1.0 version and WordPress proposes the 4.1.1 version. Changing one of them, or both we can control what kind of changes are allowed.
Finally, the last filter called allow_dev_auto_core_updates, only has got effect if we are running a developement version of WordPress, something similar to 4.1.alpha-23000 version. Only in these cases, the filter allow_dev_auto_core_updates will works, for example, for changing from the 4.1.alpha-23000 version to the 4.1.beta1 version.
Controlling individually the updating of a concrete theme, a plugin, etc. Type Filters again.
The boolean use of all of former filters usually is enogh for controlling the WordPress environment behaviour however, in those cases where we need control the updating of an specific element (only one theme, two plugins or a concrete translation, for example) but not the rest of elements of this Type, we can introduce a more accurated system of control but, to do this, we have to return to the Type filters though in that case, we’ll use the second parameter of these filters instead of the first one.
The second parameter of the Type filters is an object that contains the data about which element is been updated so that reading this object, we can decide individually whether we allow (returning TRUE) or block (returning FALSE) to the updating of this element. An example of using this second parameter through a filter for controlling plugins could be this one.
<?php
function control_two_plugins ( $allow, $item ) {
// Array of plugin that we always block
$blockedPluginArray = array (
'forms-optimizer',
'forms-translator',
);
if ( in_array( $item->slug, $blockedPluginArray) ) {
return FALSE; // Always blocked
} else {
return $update; // Here, we use the same value of $update that arrives to the filter
}
}
add_filter( 'auto_update_plugin', 'control_two_plugins', 10, 2 );
?>
Well, taking advantage two ago WordPress had a minor Update, I thought that it could be a good idea to explain How to control or modify this silent module of WordPress. I hope that it will be helpful.
Have a nice WordPressing!