This makes the library more resilient and less likely to break due to cron-related bugs in other plugins. See this commit for an analysis of one such bug: YahnisElsts/plugin-update-checker@5aee0d7b8b
Analysis:
- PluginUpdateChecker creates a custom cron schedule by using the cron_schedules filter. This schedule is used to run periodic update checks.
- BackupBuddy also creates a number of custom schedules using the same filter. However, its filter callback throws away any schedules defined by other filters/plugins and re-initializes $schedules with an empty array().
- As a result, if the filter that was added by BackupBuddy runs *after* the filter added by PluginUpdateChecker, our custom schedule is destroyed.
- When WordPress tries to re-schedule our event after a successful Cron run, it discovers that the required schedule no longer exists, and fails. On the next page load, the library detects that the event is not scheduled and schedules it again. Hence infinite loop.
- Fixed by moving our cron_schedules filter to a later priority.
Notes:
This is the *second* time I have to add a workaround for some arrogant oversight perpetrated by BackupBuddy developers. (The first one was the "plugins_api" thing, IIRC).
Essentially, the library just switches to using /wp-admin/network/plugins.php instead of /wp-admin/plugins.php as necessary. Also, the "all_admin_notices" action runs in both normal and Network admin, so it's a better choice for displaying the update check result than either "admin_notices" or "network_admin_notices".
Pass the plugin slug in a separate "puc_slug" query parameter when doing a manual update check. This way displayManualCheckResult() can verify that the current "puc_update_check_result" value applies to the right plugin.
If several active plugins include the update checker library we might end up with a bunch of different versions being loaded. In the previous implementation, whichever version was loaded first would take precedence. This is obviously a problem if an old version gets loaded and one of the plugins relies on features that are only available in the latest version.
The best way to fix this would be to delay library loading until all plugins have been loaded, then only load the latest available version. Unfortunately this approach would not be backwards-compatible with previous versions that just load the library right away. Another good way to fix the problem would be to put the entire library in a versioned namespace. Alas, namespaces are only available in PHP 5.3 and WordPress only requires PHP 5.2.
So what I've done is to put the version number in the class name and create a factory that will keep track of available versions and let you instantiate the latest one. Note that internal classes like PluginUpdate and PluginInfo still refer to specific implementations for internal consistency and backwards-compatibility.
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