Apparently, upgrading a plugin that uses PUC 4.9 to a version that uses PUC 4.10 may trigger two fatal errors, one of which happens inside the Debug Bar extension. Cause is unclear and the errors are not reproduced, but I suspect it has to do with PUC trying to set up a Debug Bar panel after the currently active PUC version has already been replaced. This patch should fix that.
By default, PUC automatically checks for updates immediately after the user upgrades the plugin or theme. This can become a problem if the upgrade overwrites the PUC library with a different version. While checking for updates, PUC may attempt to autoload a class, which will trigger a fatal error if the class file was deleted during the upgrade.
Fixed by checking if the running PUC version still exists after the upgrade. If it doesn't, remove hooks and stop.
In certain configurations, PUC could call a method that uses the $package property before calling the parent class constructor that initialises that property. This has now been fixed by moving the parent constructor call a few lines up.
Fixes#335
This helps spread out update requests over all hours of the day and may prevent the update server from being hit with daily traffic spikes.
See #323 for discussion.
To allow WP to download a release asset from GitHub, the update checker needs to add an "Accept: application/octet-stream" header to the HTTP request. We use the "http_request_args" filter for that.
Previously, we used a static variable to ensure that the filter callback is added only once. However, in PHP, static variables defined in a method are shared by all instances of the class that the method belongs to. This means that if one plugin enables release assets, adds a "http_request_args" filter, and sets ``$filterAdded` to `true`, then the next plugin that enables release assets won't add its own filter because the variable will already be `true`.
Fixed by using an instance variable (`$downloadFilterAdded`) instead of a static variable.
See #300. Apparently, when using the `files` autoloading mechanism, Composer will only include the files for one version of the library (i.e. the first one loaded). Let's see if we can fix that by switching to a `psr-0` autoloader. This requires a bunch of changes to the standalone autoloader and the factory registration process.
PUC automatically changes "tested up to" version numbers that are in the major.minor format to major.minor.latest-patch to prevent WP from showing "this update hasn't been tested with your WP version" warnings. (This was implemented because WordPress.org does something similar.) Previously, this adjustment didn't happen when the user clicked the "view details" link in a plugin update notification, so they would still see a compatibility warning there. That has now been fixed.
Fixes#307
Previously the update checker used a mix of 2.0 and 1.0. Version 1.0 was deprecated a while ago and has now stopped working for at least some users.
This should fix the errors reported in #289.
PUC uses parse_url() in a number of places to parse the metadata URL or repository URL. If someone provides an invalid URL then that's already a configuration error so it's not necessary to hide the warnings emitted by parse_url().
Also, as of PHP 5.3.3, parse_url() no longer emits warnings when it fails to parse something, so anyone using an actively supported PHP version (7.2+) wouldn't see any warnings anyway.
The filter 'puc_get_vcs_service' will then allow user to add their self hosted gitlab or bitbucket as a recognised service
like so
add_filter('puc_get_vcs_service', function($service, $host) {
if ($host == 'gitlab.mydomain.com') {
return 'GitLab';
}
return $service;
}, 10, 2);
Yahnis Elsts
Richard Coffee
Malte Müns
David Anderson
Pierre
Adrien Foulon