WordPress performs some unnecessary plugin update checks

[siliconforks]

In the function wp_update_plugins(), it seems clear that the intent is not to check for updates if there has already been an update check recently (e.g., on the wp-admin/plugins.php page, "recently" means within the last hour). However, in some cases it will check for updates anyway because of subtle issues in the implementation.

The easiest way to reproduce the issue is to install the ​Query Monitor plugin (to view HTTP requests) and then perform the following steps:

1. Visit the admin section "Updates" page (wp-admin/update-core.php). Look at Query Monitor's "HTTP API Calls" - you should see a call to ​https://api.wordpress.org/plugins/update-check/1.1/ to check for plugin updates. (You might also see additional HTTP API calls for theme and core update checks.) Note: if you don't see the plugin update check, it's possible that there was already a check for updates in the last minute - update-core.php is supposed to check for updates no more than once per minute. Try waiting a minute and reloading the page.

2. Once you have seen the plugin update check being made, visit the "Plugins" page (wp-admin/plugins.php). Look at "HTTP API Calls" - you will see another plugin update check being made. This doesn't make much sense, because WordPress just checked for plugin updates on the update-core.php page.

3. Note that the additional update check in only occurs once. Try reloading the plugins.php page and look at "HTTP API Calls" again - this time there will be no plugin update check (which is the expected behavior, since WordPress just checked for plugin updates).

Looking at the code for wp_update_plugins(), it seems that the update_plugins transient is sometimes stored with a checked property, sometimes not. This doesn't make sense to me - when the checked property is not stored in the transient, the next call to wp_update_plugins() will always check for updates regardless of how recently the last update check occurred.

[siliconforks]

proposed fix

[johnbillion]

Thanks for the report and the patch @siliconforks . Sorry that it's taken so long to get a response.

This patch looks good but it needs some testing and a sanity check by someone familiar with this component.

[bookdude13]

Hey all, thanks for the patience on this issue :)

I can confirm that this behavior still exists in trunk as of today. I was also able to get the second request simply refreshing the update page after seeing the first plugin update request. After the second request there were no more until the 1min timeout was reached, then this could be repeated.

The patch applied cleanly and solved the described bug (no more double requests). I am new to this component though, so a sanity check is still needed.

[pbiron]

refreshing patch

[pbiron]

44118.diff​ refreshes the patch so that it applies cleanly.

[francina]

I tested the patch today

• MacOS 11.4
• Safari 16611.2.7.1.4
• wordpress-develop
• WordPress 5.8-beta1-51132-src

I can reproduce the issues, but the patch doesn't apply. This is the result I get

Hunk #1 succeeded at 151 with fuzz 1 (offset -145 lines).
Hunk #2 FAILED at 182.
Hunk #3 succeeded at 424 with fuzz 1 (offset 8 lines).
1 out of 3 hunks FAILED -- saving rejects to file src/wp-includes/update.php.rej

And here is what I have in the file:

*** 179,184 ****
  		$plugin_changed = false;
  
  		foreach ( $plugins as $file => $p ) {
  			if ( ! isset( $current->checked[ $file ] ) || (string) $current->checked[ $file ] !== (string) $p['Version'] ) {
  				$plugin_changed = true;
  			}
--- 182,189 ----
  		$plugin_changed = false;
  
  		foreach ( $plugins as $file => $p ) {
+ 			$new_option->checked[ $file ] = $p['Version'];
+ 
  			if ( ! isset( $current->checked[ $file ] ) || (string) $current->checked[ $file ] !== (string) $p['Version'] ) {
  				$plugin_changed = true;
  			}

I think the patch needs a refresh :) Thanks!

[siliconforks]

Refreshed patch to work after r50921 (which added support for the Update URI header)

[siliconforks]

Refreshed patch to work after r54891 (which modified coding standards to require parentheses for calls to constructors)

[siliconforks]

The previous patch no longer applied cleanly due to a coding standards change - I've uploaded a refreshed version.

Also, as this bug report approaches its fifth anniversary, it seems that there's not a lot of interest in fixing this issue... I'd just like to point out that I don't think I'm the only WordPress user who would like to see a fix for this; there appears to be some broader concern in the WordPress community that WordPress is performing an excessive number of outgoing HTTP requests. This project aims to make a plugin which will reduce these:

​https://www.cloudfest.com/eco-mode-reduce-outgoing-network-traffic-of-your-wordpress-server

That plugin might indeed be useful; however, I think it would be even better to fix any issue in the WordPress core which may be causing it to perform unnecessary HTTP requests in the first place...