Make WordPress Core

Opened 4 years ago

Last modified 4 years ago

#49626 new feature request

Allow plugin developers to opt-out their plugin from auto updates

Reported by: jaworskimatt's profile JaworskiMatt Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Plugins Keywords:
Focuses: Cc:


I would like to request a filter for plugin developers to be able to opt their plugin out from the automatic updates completely.

For example in wp_autoupdates_add_plugins_autoupdates_column_content we could add something like

if ( !apply_filters('wp_autoupdates_enabled_for_plugin', TRUE, $plugin_file)) {

This way a developer of a plugin that for some reason should always be updated manually, can hide this option from the admin for his own good.

Change History (5)

#1 follow-up: @TimothyBlynJacobs
4 years ago

Thanks for your ticket @JaworskiMatt!

I think there is a filter that would already be usable for this purpose: `auto_update_{$type}`.

add_filter( 'auto_update_plugin', function ( $update, $item ) {
        if ( $item->plugin === 'your-plugin/your-file.php' ) {
                return false;

        return $update;
}, 10, 2 );

#2 in reply to: ↑ 1 @JaworskiMatt
4 years ago

Replying to TimothyBlynJacobs:

Thank you, but it doesn't seem to disable the "enable auto updates" link in the plugin list view.

What's even worse, the link is there even if the plugin is inactive, meaning we can't control it with filters.

It seems the only way would be adding something to the plugin header to force WordPress into not presenting this option at all.

It means, auto updates can mess things up if an automatic update kicks in for plugin A which relies on some classes / methods from plugin B.

#3 @knutsp
4 years ago

Two things:

  1. Active plugins: The auto-update link should only show for if this filter returns true.
  2. What is the use case for inactive plugins wanting to opt out of auto-updates?

A plugin or theme has no influence over how WordPress behaves while inactive. Current headers apply restrictions when activated, or trying to. So this would introduce something new, not only as a feature, but in principle.

Active plugins turning off auto-updates, like backup plugins and other plugins running tals in the background, may have a good reason, plus any plugin can do anything, in principle.

I'm inclined to think any thing, even things about itself, is no business for an inactive plugin. Auto-updates is part of core. I, as an admin, may want to auto-update all of my inactive plugins and should not have to hack it to achieve it, regardless of what the plugin author thinks. But, if there is a clear and distinct reason for letting plugin authors dictate this while their plugin as inactive, I may change my mind.

#4 @JaworskiMatt
4 years ago

I’m not talking about turning off auto updates for the whole site, just every plugin for itself (activated or not). Our plugins are dependent on one another, updating one but not another can prevent the “child” plugins from initializing their hooks (we prevent a potential whitescreen at an expense of disabling certain features).

Our users know that, but an automatic system won’t - and there is no plugin-to-plugin dependency system in WP (ie don’t update plugin A to ver X if plugin B is not at least ver Y).

In theory it shouldn’t be a problem if we push all updates at the same time - which we do - but some our plugins are served from and some aren’t and there is no way to make sure these things are synced. Every release we get a bunch of tickets “I updated X and now Y is not working” only because someone didn’t read the manual and updates from one source popped up before updates from another. I expect it to get worse with autoupdates in place.

I can only imagine what kind of havoc might be wrecked if someone is using interdependent plugins from various vendors, being talked into “always updating cause it’s safer”.

Granted it’s not as bad for inactive plugins, as they can’t screw anything up until activated - and our version locks will take care of that. So I suppose what we actually need is being able to turn it off once plugin is active, even if admin decided otherwise when it wasn’t (which is just another way around the same task).

Either way it’s too late to put anything in 5.5 and this auto update stuff seems to be shipped with it. So we will need to find other ways to cope with that in our product.

We figured out we can override the column HTML in the plugin listing as long as at least one of our plugins is active - thus killing the auto update feature for our entire suite. Now we just need to make sure we opt ourselves out retroactively in case someone enabled auto update before updating our plugins, and we should be (mostly) fine. We will also keep telling our users to stay away from autoupdates of our plugins, like we always did (only before it wasn’t a part of Core, so now our education efforts need to be doubled).

Last edited 4 years ago by JaworskiMatt (previous) (diff)

#5 @knutsp
4 years ago

Thank you for the detailed explanation. (I never meant for the whole site.)

Checks for main plugin version should be made when a dependent plugin is active or being activated. This is done by many plugin authors already, especially "pro" addon plugins.

I support your request for being able to hide enabling of auto-updates, when such enabling will have to effect due to filter. I should show "auto-updates disabled" with no link to enable, preferably with some short explanation.

Note: See TracTickets for help on using tickets.