Non-repo plugins with updates available not listed on updates screen

[lumpysimon]

Plugins with updates available, but which are not hosted on the WordPress plugin repo, are not showing on wp-admin/update-core.php

The update counts in the toolbar and admin menu correctly show the updates as being available. The updates are also available via wp-admin/plugins.php

wp-admin/update-core.php says that plugin updates are available, and shows an empty table (see attached screenshot).

I've reproduced this issue on three websites with the following plugins: Gravity Forms PayPal Standard Add-on; WP Rocket; Events Manager Pro.

[lumpysimon]

Screenshot of wp-admin/update-core.php with empty plugins list

[nacin]

Is this new to 4.1?

[lumpysimon]

Replying to nacin:

Is this new to 4.1?

Yes

[johnbillion]

Possible culprit: [30696]

[helen]

I can confirm this on a site with Gravity Forms. Moving to 4.1.1 for consideration, as that looks really lame.

[valendesigns]

This is actually a simple fix if I'm correctly understanding what's happening in update-core.php. We just need to check that the package URL is for a WordPress Directory plugin or the UI doesn't load because of a continue when plugins_api returns a WP error. In some implementations like the Github Updater, the slug being filtered is actually different than $plugin_data->update->slug. It also includes the plugin file name. So the response doesn't get filtered and the code is allowed to run thinking it's a WP directory plugin, even though it's not.

[valendesigns]

I've just added another patch. This one doesn't check if the package path if for WordPress, but attempts a second plugins_api request using $plugin_file as the slug. This fixes the issue for plugins that use the Github Updater, or at least the version I tested. I would need access to more plugins to really go much further.

Are there any free plugins that I can download and test with? Gravity Forms is not free and buying it to test this issue is just out of the question. I need at least one plugin that doesn't use the Github Updater script.

[valendesigns]

The first patch seems to work better when you deactivate the plugin and there's an update available. The second patch got confused and reverted back to an empty table, while the first one remained persistent until _site_transient_update_plugins was rebuilt. The reason is now obvious. The plugin can no longer filter the response since it's deactivated and update information still exists in the database so WP thinks theres something to update.

Possibly some variation of the two techniques combined could work more consistently. In either case, I need more plugins to test with. I'll check back for responses tomorrow morning and hopefully we'll get this sorted.

[dd32]

Can someone attach a basic plugin which uses a updater which can be used to duplicate the bug?

It's not immediately clear if making a second plugins_api call is the best option here, if the bug is in the 3rd party updater code, or if we need to check for the external field on the update api response or something.

[valendesigns]

I'm definitely leaning towards the first patch over the second one, especially after testing a bit more last night. Since there are checks for isset all over the list_plugin_updates function we are pretty safe in letting it move forward when it's not a WP repo plugin. Obviously we can't know all the different ways people implement non-repo updates but at least we're not stopping them from showing anymore. The issue with checking if the response is external is that we're assuming they are filtering on the plugin slug and the plugin is still activated. It could very well have been deactivated recently but the update info is still saved in the database. In that situation update-core.php would think there is an update but list_plugin_updates would fail to produce the correct information when we run plugins_api. Not a huge issue, but does mean there will be an empty table until the cashed update info is rebuilt.

[dd32]

In 31382:

Updates: Display plugin update rows even for plugins which are not hosted by WordPress.org or the HTTP request times out on.
See #29583.
Fixes #30767 for trunk.

[dd32]

In 31383:

Updates: Display plugin update rows even for plugins which are not hosted by WordPress.org or the HTTP request times out on.
See #29583.
Merges [31382] to the 4.1 branch.
Fixes #30767.