While most PUC class names use version number suffixes to avoid conflicts with older versions of the library, the classes responsible for Debug Bar integration did not (until now). This is because those classes are fairly simple and they have stayed mostly unchanged since version 1.0. Mostly, but not completely. For example, the debug bar panel depends on the getCronHookName() function, and that function was recently moved to the new PucScheduler class.
This is a problem because when your site has two plugins using two different versions of this library (e.g. 3.0 and 1.3), you can end up in a situation where PluginUpdateChecker_3_0 unintentionally instantiates the old version of PluginUpdateCheckerPanel (1.3). Then the panel then tries to access a non-existent field or method of PluginUpdateChecker_3_0 and crashes. It produces errors like this:
[26-Apr-2016 13:34:14 UTC] PHP Fatal error: Call to undefined method PluginUpdateChecker_3_0::getCronHookName() in [redacted]\wp-content\plugins\plugin-name-here\inc\plugin-updates\debug-bar-panel.php on line 58
Fixed by versioning debug bar panel class names.
In theory, $state and $state->update should always be either NULL or objects. That means isset() fully covers the possibilities and we don't need the additional empty() checks.
Support both PHP 7 and PHP <5.3
Load different versions of the Parsedown library depending on the PHP version. This will only affect plugins that use the GitHub update checker because the usual checker doesn't need to parse Markdown.
It appears that WordPress core developers are planning to add the `tested` and `compatibility` fields to the bulk update check API. Previously WordPress had to make a separate API request for each plugin to retrieve this information. See this Trac ticket for details:
https://core.trac.wordpress.org/ticket/35301
The `tested` field is used to generate the "Compatibility with WordPress X.Y: 100% (according to its author)" message on the "Dashboard -> Updates" page.
Note: This library doesn't support the `compatibility` field, so that's not included.
The non-versioned variants of the update checker classes were removed: PluginUpdateChecker, PluginUpdate, PluginInfo. The original purpose of these aliases was to allow plugins that used the first version of PUC to easily upgrade to a newer version of the library without changing their code. However, as the update checker has evolved over time, that is no longer safe - e.g. version 3.0 might not be fully backwards-compatible with version 1.0.
If you were using the plain PluginUpdateChecker class, use this instead:
- `new PluginUpdateChecker_x_y(...)` - replace x_y with the library version number. This will create an instance of the specific version that's bundled with your plugin, which is best for compatibility with other plugins.
- `PucFactory::buildUpdateChecker()`. This will instantiate the newest loaded version, even if it was loaded by some other plugin and not yours. Simpler to use is some ways, but be prepared to support the latest version of the update checker.
No need to check if is_network_admin() and switch between network_admin_url() and admin_url(). Turns out, WordPress already has a utility function that does that.
Yahnis Elsts
Bas de Kort
Nicolas GEHIN
Tamás András Horváth