Show when updates are disabled vs not available

[paulschreiber]

It would be helpful to show when updates are disabled vs not available.

Context:
Yesterday, I was fixing a site and noticed some plugins weren't updating. No updates showed as available in the GUI, and the CLI showed "Plugin already updated":

$ wp plugin update ultimate-member
Success: Plugin already updated.

I had to remove and reinstall to get it working;

$ wp plugin uninstall ultimate-member
Uninstalled and deleted 'ultimate-member' plugin.
Success: Uninstalled 1 of 1 plugins.

$ wp plugin install ultimate-member
Installing Ultimate Member – User Profile, User Registration, Login & Membership Plugin (2.1.12)
Downloading installation package from https://downloads.wordpress.org/plugin/ultimate-member.2.1.12.zip...
Using cached file '/home/u331-eccke9yc2pw5/.wp-cli/cache/plugin/ultimate-member-2.1.12.zip'...
Unpacking the package...
Installing the plugin...
Plugin installed successfully.
Success: Installed 1 of 1 plugins.

In this case, someone had disabled updates with a filter (eek!):

<?php
// disables auto plugin updates
add_filter( 'auto_update_plugin', '__return_false' );

// hide update notifications
function remove_core_updates(){
global $wp_version;return(object) array('last_checked'=> time(),'version_checked'=> $wp_version,);
}
add_filter('pre_site_transient_update_core','remove_core_updates'); //hide updates for WordPress itself
add_filter('pre_site_transient_update_plugins','remove_core_updates'); //hide updates for all plugins
add_filter('pre_site_transient_update_themes','remove_core_updates'); //hide updates for all themes*/
?>

As a result of updates being disabled, security updates were not installed and the site was hacked.

It would be very helpful for both the GUI and CLI to show "updates disabled" instead of "already updated"/"no updates available."

I believe we'd need core/API change here first, and then CLI could adopt that.

[pbiron]

Hi @paulschreiber.

I think it would be really hard (if not impossible) to detect that all updates (manual and auto) were disabled (by a plugin mucking with the site transients as shown in your example). So I'm not sure what change we could make in core to alert site admins to kind of situation you faced.

Hooking into the pre_site_transient_update_XYZ filters is how many plugins/themes that are not hosted in the .org repo make their updates known. So simply checking whether those filters were hooked would provide too many false positives.

Not saying that we shouldn't try to come up with a means of warning site admins, but again, not sure how would we do that.

[paulschreiber]

@pbiron Rough sketch:

• reach out to server for updates, and cache array of values, A1
• apply auto_update_plugin / auto_update_theme filters, resulting in an array, A2
• if A1[n] == update and A2[n] == no update, print "update disabled"
• if A1[n] == no update and A2[n] == no update, print "no update available"
• if A[1n] == update and A2[n] == update, print "update available"

If it makes it easier, a v1 solution could only consider wordpress.org-hosted updates? That would help, even if it doesn't handle 100% of cases.

[pbiron]

The auto_update_{$type} filters don't affect whether manual updates are offered...only auto-updates...so the logic in your "rough sketch" wouldn't report that all update offers were disabled.

Question: was the code you show that defined remove_core_updates() in a "site-specific" plugin or in a general purpose "control updates" plugin?

Given the specifics of remove_core_updates() we could detect that all update offers were being removed (since the updates property of site_transient_update_core and no_update and response properties of site_transient_update_{plugin|theme} aren't present) but that is far from a general solution (even limited to .org responses).

[paulschreiber]

The update-disabling snippet above was in theme code (!) in functions.php. It wasn't part of a update-disabling plugin and wasn't explained or documented.

[pbiron]

Is the theme a "general purpose" theme (either .org or premium) or a site-specific theme?

[paulschreiber]

This was a site-specific / custom theme.

[pbiron]

On a hunch, I did a little Google searching that turned up what I think is the origin of that code: ​https://thomas.vanhoutte.be/miniblog/wordpress-hide-update/.

Looks like the author of the site-specific theme just copied the snippet without thinking of the consequences (not to mention that the author of that blog post didn't think about the consequences, despite ending the post with "While you won’t be notified about any new version of WordPress with these settings, I strongly recommend to check for updates manually."...given that his snippet prevents site admins from 'checking for updates manually' :-(