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.
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.
WordPress has a security feature where the HTTP API will reject all requests that are sent to another site hosted on the same server as the current site (IP match) or a local host/IP, unless the host exactly matches the current site. This feature is opt-in, but apparently some people (or security plugins?) enable it.
This can be a problem when the update metadata is on the same server as your site, but not on the exact same hostname. The aforementioned security restriction will cause updates to fail for no apparent reason.
The patch fixes the issue by using the "http_request_host_is_external" filter to explicitly allow the host that the metadata URL points to.
Now PluginInfo will always trigger a PHP notice if it receives invalid JSON or the input doesn't pass some (basic) validation. In practice, you should never encounter this notice if you've set up your metadata correctly.
Make it a public method: isPluginBeingUpgraded(). This method returns true if the plugin associated with the update checker is currently in the process of being updated.
This can be useful for plugins that hook into WordPress core to change how WordPress installs updates. For example, if you were using the "upgrader_pre_download" filter, you could call this method to verify that the update being downloaded is for your plugin and not another one.
Caution: The method is not guaranteed to be accurate.
Yahnis Elsts
Tamás András Horváth
Hareesh
dangoodman