What is a "forced plugin update", how can I avoid it and use it for my plugins

Question

Following a twitter discussion it seems like wordpress.org have the ability to push security updates for plugins even to sites which didn't opt-in into receiving automatic plugin update. Can anyone explain the rational for it and how can I block this kinds of updates?

On the other hand, is this functionality is limited by "magic" to wordpress.org, or can I use the same mechanism to update plugins and themes that are distributed from my own server while remaining conformant to the general update process and rules of wordpress core (obviously in my code I can bypass everything to trigger an update, the question is how do I align best with user expectations as expressed by setting up constants or usage of various update related filters).

Answer 1

To answer the first question...

If you look within the WP_Automatic_Updater class found in wp-admin/includes/class-wp-upgrader.php we note the method is_disabled which is used by the method should_update to determine whether or not an automatic update is allowed.

The is_disabled method will return true under the following conditions,

• if DISALLOW_FILE_MODS constant is defined and is true
• if WP_INSTALLING constant is defined regardless of value state
• if AUTOMATIC_UPDATER_DISABLED constant is defined as true

Be aware though that the latter constant AUTOMATIC_UPDATER_DISABLED is also associated with a filter, automatic_updater_disabled, so even if defined, it is possible for the value to be filtered elsewhere in which case you are best served by declaring the following hook:

add_filter( 'automatic_updater_disabled', '__return_true' );

Here is the method excerpt from the WP_Automatic_Updater class:

wp-admin/includes/class-wp-upgrader.php:1730

/**
 * Whether the entire automatic updater is disabled.
 *
 * @since 3.7.0
 */
public function is_disabled() {
    // Background updates are disabled if you don't want file changes.
    if ( defined( 'DISALLOW_FILE_MODS' ) && DISALLOW_FILE_MODS )
        return true;

    if ( defined( 'WP_INSTALLING' ) )
        return true;

    // More fine grained control can be done through the WP_AUTO_UPDATE_CORE constant and filters.
    $disabled = defined( 'AUTOMATIC_UPDATER_DISABLED' ) && AUTOMATIC_UPDATER_DISABLED;

    /**
     * Filter whether to entirely disable background updates.
     *
     * There are more fine-grained filters and controls for selective disabling.
     * This filter parallels the AUTOMATIC_UPDATER_DISABLED constant in name.
     *
     * This also disables update notification emails. That may change in the future.
     *
     * @since 3.7.0
     *
     * @param bool $disabled Whether the updater should be disabled.
     */
    return apply_filters( 'automatic_updater_disabled', $disabled );
}

I would further suggest the following link for reading:

Configuring Automatic Background Updates

http://codex.wordpress.org/Configuring_Automatic_Background_Updates

...which provides in detail a list of the available constants and filters for fine grain control over what components to disable against updates.

For the case of only disabling automatic plugin updates you have:

add_filter( 'auto_update_plugin', '__return_false' );

...and so forth.

To answer your second question...

(someone correct me if I am wrong)

Let's add some context for the readers, this entire question is as a result of this twitter status which was in itself a response to the forced automatic update of Yoast's WP SEO plugin see the following, https://yoast.com/wordpress-seo-security-release/, for more information.

There is a function in wp-includes/update.php named wp_maybe_auto_update which is fired on the hook with the same name do_action('wp_maybe_auto_update') which is fired from within the wp_version_check function contained within the same file which in itself is a scheduled event that runs twice daily.

So, what I suspect WordPress.org did, was that they internally incremented the version of WordPress so that an automatic update would be forced onto users due to the apparent severity of the security flaw associated with the Yoast WP SEO plugin.

To quote Yoast himself:

Because of the severity of the issue, the WordPress.org team put out a forced automatic update (thanks!)

I'm not 100% certain whether this in fact then also automatically updated any other plugins that had new versions in the WordPress.org repository or whether or not WordPress.org can dictate which plugins can be auto-updated from their end, perhaps there something within the code that also allows for this type of discretion.

As to whether or not you can use the same mechanisms yourself, well, for plugins that you host within the WordPress.org repository, yes, for those outside of the official repository, I'm not entirely sure, but you may be able to instantiate the WP_Automatic_Updater class and provide it a context for which to check against but I think ultimately we end up in function called wp_update_plugins within wp-includes/update.php which checks against the official WordPress repository API.

I may be incorrect so if anyone has something further to add, please chime in.