Over the past couple of years when maintaining Easy Updates Manager - https://wordpress.org/plugins/stops-core-theme-and-plugin-updates/ - we've had a lots of reports from people with third party plugins and themes whose upgrades aren't detected or performed. On investigation, this is invariably because the component loads PUC only during an `admin_*` hook, which means that those updates are effectively invisible except for a logged-in user viewing a page in the WP dashboard. So, tools like EUM, ManageWP, JetPack Manage, UpdraftCentral, WP-CLI, etc., don't see them - they're invisible.
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.