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.
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
This may look like a lot of changes, but it's essentially a simple search & replace from "v4" to "v4p1". Note that the factory class name stays the same: Puc_v4_Factory. It will only change on a major release.
Move most GitHub and BitBucket stuff to a general "VCS checker" class and put service-specific logic in API classes that follow a common interface.
Rationale: Upon further reflection, there's no need to have different theme & plugin checker implementations for each Git hosting service. The overall update detection algorithm stays the same. Only the API and authentication are different.
Not entirely happy with the code duplication in Vcs_PluginUpdateChecker and Vcs_ThemeUpdateChecker. Traits would be one solution, but can't use that in PHP 5.2. There's probably a "good enough" way to achieve the same thing through composition, but I haven't figured it out yet.
For private GH repositories, use setAuthentication('access_token_here') instead of setAccessToken().
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.
Yahnis Elsts
aaronkirkham07@gmail.com