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.
This bug was caused by a combination of two facts:
1) The version that gets loaded first takes the Puc_v4_Factory alias.
2) All other versions register their class names with the existing Puc_v4_Factory, not their own factory class.
We can't really do much about the first one, but we can work around the second one by also registering each class with the version-specific factory.
See also #279