Make WordPress Core

Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#30767 closed defect (bug) (fixed)

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

Reported by: lumpysimon's profile lumpysimon Owned by: dd32's profile dd32
Milestone: 4.1.1 Priority: normal
Severity: normal Version: 4.1
Component: Upgrade/Install Keywords: has-patch needs-testing
Focuses: Cc:


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.

Attachments (3)

wp4.1-plugin-upgrade-problem.png (61.1 KB) - added by lumpysimon 8 years ago.
Screenshot of wp-admin/update-core.php with empty plugins list
30767.diff (556 bytes) - added by valendesigns 8 years ago.
30767.1.diff (621 bytes) - added by valendesigns 8 years ago.

Download all attachments as: .zip

Change History (14)

8 years ago

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

#1 follow-up: @nacin
8 years ago

  • Keywords reporter-feedback added

Is this new to 4.1?

#2 in reply to: ↑ 1 @lumpysimon
8 years ago

Replying to nacin:

Is this new to 4.1?


#3 @johnbillion
8 years ago

  • Keywords needs-testing added; reporter-feedback removed

Possible culprit: [30696]

#4 @helen
8 years ago

  • Keywords needs-patch added; needs-testing removed
  • Milestone changed from Awaiting Review to 4.1.1

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

8 years ago

#5 @valendesigns
8 years ago

  • Keywords has-patch needs-testing added; needs-patch removed

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.

8 years ago

#6 @valendesigns
8 years ago

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.

#7 @valendesigns
8 years ago

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.

#8 @dd32
8 years ago

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.

#9 @valendesigns
8 years ago

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.

#10 @dd32
8 years ago

  • Owner set to dd32
  • Resolution set to fixed
  • Status changed from new to closed

In 31382:

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

#11 @dd32
8 years ago

In 31383:

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

Note: See TracTickets for help on using tickets.