wp_get_update_data() calls are not pluggable

[szepe.viktor]

Up to 4.1 I was able to disable core, themes and plugin updates and related HTTP traffic.

​https://github.com/szepeviktor/wordpress-plugin-construction/blob/7b64d0ca4981b163b2f08adbe14a5b5238800bd8/mu-disable-updates/disable-updates.php

In 4.1 new wp_get_update_data() calls are much like hardcoded than pluggable, I wasn't able to disable them all. Especially not the ones in wp-admin/menu.php

​https://github.com/WordPress/WordPress/blob/master/wp-admin/menu.php#L33-L34
​https://github.com/WordPress/WordPress/blob/master/wp-admin/menu.php#L183-L187

Could you make wp_get_update_data() calls pluggable? Or give me an advise to disable them?

My current workaround is to fiddle with the transients:
​https://github.com/szepeviktor/wordpress-plugin-construction/blob/master/mu-disable-updates/disable-updates.php#L98

Thank you!

[jorbin]

do the following filters in place already not work for this?

remove_action( 'admin_init', '_maybe_update_core' );
remove_action( 'admin_init', '_maybe_update_plugins' );
remove_action( 'admin_init', '_maybe_update_themes' );

[szepe.viktor]

​https://github.com/WordPress/WordPress/blob/master/wp-admin/menu.php#L31-L32
Here you can see that wp_get_update_data() is executed without condition.

The only way to make it ineffective is to alter the transient's value.

Actually the transients could contain update data because my mu-plugin allows update by pushing the "Check again" button.

[desrosj]

Sorry that this one took so long to receive a follow up @szepeviktor.

Though it's not the only factor, I'm tempted to close this one out as wontfix because it seems that this is the only request for this in the 9 years that have passed.

For the initial request to make wp_get_update_data() function pluggable, that is a pattern that Core has moved away from and not something that will be implemented. Some new action or filter hooks can be considered if reasonable and beneficial.

I looked at wp_get_update_data() and unless I'm missing it, that function does not result in any HTTP traffic (though it's possible that it did previously). It appears to only grab the related transients from the database and return the relevant parts. If the transients are not set or expired, it won't attempt to determine if there are updates.

There is the wp_get_update_data filter that allows you to change the values returned by the function. I'm wondering if that works better for you than the pre_site_transient_* filters. Another way to address this would be adding a pre_* short-circuiting filter to return a custom generated value before the function's logic runs.

But given that this will not help accomplish your intended goal of stopping all update related HTTP traffic (and questionable whether Core should make disabling updates like that easier), I think it's better to just close this out as wontfix. I'm going to mark as close candidate and allow a few weeks for additional feedback before closing out in case there are additional opinions.