Plugins page keeps making HTTP requests for plugin dependencies which are not in the WordPress Plugin Directory

[siliconforks]

Suppose you have two plugins installed, foo and bar, and foo is a dependency of bar.

<?php

/*
Plugin Name: Bar
Requires Plugins: foo
*/

Suppose also that foo and bar are not in the WordPress Plugin Directory - they are custom plugins or third-party plugins installed from elsewhere.

Then, every time the Plugins admin page is visited, WP_Plugin_Dependencies::get_dependency_api_data() will make an HTTP request for information on foo:

https://api.wordpress.org/plugins/info/1.2/
?action=plugin_information
&request%5Bslug%5D=foo
&request%5Bfields%5D%5Bshort_description%5D=1
&request%5Bfields%5D%5Bicons%5D=1
&request%5Blocale%5D=en_US
&request%5Bwp_version%5D=6.7

Normally, for a plugin which is found in the WordPress Plugin Directory, the response to this request would be cached in a transient for 12 hours, and there would not be any need to repeat the HTTP request for plugin information during that time. However, because foo is not in the Plugin Directory, the response will return 404 Not Found, and this means that the HTTP request will keep getting made over and over again every time the Plugins page is visited.

Some thoughts on how to improve this behavior:

1. Maybe WP_Plugin_Dependencies::get_dependency_api_data() should cache negative responses? That is, maybe it should remember that the HTTP request returned 404 Not Found and not try the request again for 12 hours?

2. Maybe it would be wise to look at the ​Update URI header field (if it exists) and, if the value is not https://wordpress.org/plugins/{$slug}/ or w.org/plugin/{$slug}, then clearly the plugin is not in the WordPress Plugin Directory and the HTTP request for plugin information can be skipped? This seems like it would work; on the other hand, this might be considered to be (ab)using the "Update URI" header for a purpose other than that for which it was intended.

[the ank]

Hi @siliconforks, I tried to replicate this issue in my local WP. I found it keeps triggering the plugin check API, but it only triggers on the wp-admin/plugins.php page and not on other pages.

So yes, if the admin visits the plugins page multiple times, it will trigger the same API for missing required plugins not listed in WordPress.org.

Solution - When the first time this plugin API triggers, it should keep a log of required plugins not in wordpress.org and ignore those plugins to trigger check API.

Code -

$information = plugins_api(
				'plugin_information',
				array(
					'slug'   => $slug,
					'fields' => array(
						'short_description' => true,
						'icons'             => true,
					),
				)
			);

Regards

[siliconforks]

Replying to the ank:

Solution - When the first time this plugin API triggers, it should keep a log of required plugins not in wordpress.org and ignore those plugins to trigger check API.

Yes, that should basically work, but ideally it should also handle cases where developers are working on custom plugins on their own server, and then later they submit the plugins to the WordPress Plugin Directory.

Using the example above: foo might be a custom plugin, but some day in the future it might actually show up in the Plugin Directory, and at that point it would make sense to retrieve plugin information from the Plugin Directory with an HTTP request.

Issue - The plugins page keeps making HTTP requests for plugin dependencies which are not in the WordPress Plugin Directory

Solution -

File - /wp-includes/class-wp-plugin-dependencies.php
Line - 677 to 683 and 719 to 722
comment - Added by AV start and Added by AV ends

Fix - Required plugins that are not listed in wordpress.org, will have their own transient set for 12 hours and the next time before plugins_api() runs, it will check if transient exists, ignore this plugin to check in wordpress.org

[the ank]

I have created a pull request with a solution for this issue: ​https://github.com/WordPress/wordpress-develop/pull/6944