Make WordPress Core

Opened 6 years ago

Last modified 14 months ago

#44118 assigned defect (bug)

WordPress performs some unnecessary plugin update checks

Reported by: siliconforks's profile siliconforks Owned by: francina's profile francina
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Upgrade/Install Keywords: has-patch needs-testing
Focuses: Cc:


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 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.
  1. 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.
  1. 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.

Attachments (4)

fix-update_plugins-transient.patch (1.1 KB) - added by siliconforks 6 years ago.
proposed fix
44118.diff (1.5 KB) - added by pbiron 3 years ago.
refreshing patch
44118-after-update-uri-header.diff (1.4 KB) - added by siliconforks 3 years ago.
Refreshed patch to work after r50921 (which added support for the Update URI header)
44118-after-coding-standards-change.diff (1.4 KB) - added by siliconforks 14 months ago.
Refreshed patch to work after r54891 (which modified coding standards to require parentheses for calls to constructors)

Download all attachments as: .zip

Change History (12)

#1 @pento
5 years ago

  • Keywords has-patch added
  • Version trunk deleted

#2 @johnbillion
5 years ago

  • Component changed from Plugins to Upgrade/Install
  • Keywords needs-testing added
  • Milestone changed from Awaiting Review to Future Release

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.

#3 @bookdude13
4 years ago

  • Keywords 2nd-opinion added; needs-testing removed

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.

3 years ago

refreshing patch

#4 @pbiron
3 years ago

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

This ticket was mentioned in Slack in #core-auto-updates by francina. View the logs.

3 years ago

#6 @francina
3 years ago

  • Keywords needs-testing added; 2nd-opinion removed
  • Owner set to francina
  • Status changed from new to assigned

#7 @francina
3 years ago

I tested the patch today

  • MacOS 11.4
  • Safari 16611.
  • 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!

3 years ago

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

14 months ago

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

#8 @siliconforks
14 months ago

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:

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...

Note: See TracTickets for help on using tickets.