You can explicitly specify the MU-plugin basename (relative to "/wp-content/mu-plugins") as the last argument to PucFactory:buildUpdateChecker(). If you do, the "Check for updates" link and update notifications will show up in "Plugins -> Installed -> Must-Use". However, automatic update installation still won't work because WordPress does not support it for mu-plugins.
I have a need to receive extra information back from the server. In particular, I want to receive information that says "updates entitlement soon expires" or "updates entitlement already expired".
Currently, the functions in the class PluginUpdate_1_3 strip out anything not in the private $fields.
This change adds a filter to allow the consumer to retain any extra fields they wish.
The WordPress cron implementation does not guarantee that a cron hook will only be run once, or run exactly on schedule. For example, it's possible for an event to be triggered two or three times in quick succession due to race conditions. If we check for updates each time our hook is run, we could end up sending redundant update requests that waste bandwidth and server resources.
Instead, make sure at least $checkPeriod hours have elapsed since the last check before checking again. Allow for a small fuzz-factor (currently 20 minutes) to account for the inherent inaccuracy of WP cron.
This feature is disabled by default. Turn it on by setting `$checker->throttleRedundantChecks` to `true` and use `$checker->throttledCheckPeriod` to set the alternate check period (default = every 72 hours).
Caution: There might be some issues in how/when the cache is cleared. It looks fine in theory, but I may have missed something (bulk upgrades? Multisite side-effects?).
Also removed two unused parameters from addCheckForUpdatesLink(). We can always add them back later if needed.
Version bump: 1.3.2
This was suggested in #8 as a way to make the custom update checker more consistent with how WP handles plugin updates. Arguably, visiting "Dashboard -> Updates" means that the user wants to check for updates, so it's okay to ignore the configured check interval in this case.
You can still disable automatic checks by setting $checkPeriod to 0, which will also disable this additional check.
Explanation:
WordPress includes a "quick edit" function that lets users edit certain post properties (title, categories, etc) from the "All Posts" list. WP calculates the width (colspan attribute) of the inline editor based on the number of <th>'s in the header of the first .widefat table on the page. When PUC and Debug Bar are both active, that first table happens to be the debug info table in our Debug Bar panel. This table does not have a <thead>. As a result, WordPress sets the colspan to zero, making the inline editor unusable.
Fixed by removing the "widefat" class from our debug info tables and adding a bunch of new CSS to emulate WordPress table style.
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.
Yahnis Elsts
David Anderson