When multiple instances of the update checker are active at the same time, each will have its own PluginUpdateCheckerPanel instance and its own entry in the Debug Bar. However, since all instances have the same class name, and Debug Bar uses this name to generate link and wrapper IDs, we will end up with duplicate IDs and a semi-broken debug bar.
I've added a bit of JS that will find update checker panels and replace the relevant IDs with new ones based on the plugin slug, not class.
This is a significant change from previous behaviour where the library would leave the value of the "update_transients" unmodified if there were no updates available. That worked fine at the time because WP wouldn't re-save the injected update to the DB. So when no updates were available, old cached updates wouldn't show up either. However, this appears to have changed - in some cases, the injected update sticks around even if the plugin is no longer injecting it. This patch counters that.
Drawback: If you use this library in a plugin that's hosted on wordpress.org, it will overwrite any update data from wordpress.org with its own and effectively disable wordpress.org updates for your plugin (doesn't affect other plugins).
Cause: Originally the update check routine was attached to the admin_notices hook. However, the plugin list is populated long before that action.
Fixed by running the update check earlier in the request process and redirecting back to plugins.php to display the success message. As a side-effect, this will also prevent unwanted extra checks when the user reloads the page.
* checkForUpdates() now returns the update or null.
* Added a new getUpdate() method. Use it to retrieve update details (if there is an update available). It uses the internal cache, so use checkForUpdates() instead if you want the most recent info. Also, if no update is available, or if its older than the installed version, it will return null.
* Changed our plugins_api filter priority to 20 to fix a compatibility problem caused by a bug in the WooThemes plugin updater. In short, the WooThemes updater also has a plugins_api filter, and their implementation will throw away the response returned by other filters.
* The default wp_remote_get() options are now correctly filtered, not completely discarded.
* Fixed a bunch of IDE warnings about incorrectly inferred variable types.
* Increased info.json download timeout to 10 seconds.
* Be a good netizen and send the "Accept: application/json" header when asking for the info.json file.
* Don't check the plugin's version on every pageload. Too slow (get_plugins() scans all likely-looking .php files, which can be a lot).
* Pass the return value of wp_remote_get() as the second arg. of the result filter callback.
Yahnis Elsts