Previously, if the wrong base class name was written to the database, attempts to load update information could trigger a warning because there was no class_exists() check in the "updateBaseClass is set" branch. To fix that, I've moved the class_exists() closer to the place where the class name is actually used.
StateStore will still fail to load a stored update if the class name is invalid, but without a PHP warning this time. The invalid stored update information should be overwritten the next time PUC checks for updates.
This applies to locally stored plugin icons and banners. The code for icons and banners was very similar, so I've turned it into a utility method to reduce code duplication.
Props to @timwiel for the suggestion and the original implementation. See #461.
This change applies to plugins (but not themes) that are updated from a VCS hosting provider like GitHub. Previously, the plugin author would have had to use a filter to provide icons. Now they can just put them in a subdirectory named "assets" instead. Icon file names and extensions should match those described here:
https://developer.wordpress.org/plugins/wordpress-org/plugin-assets/#plugin-icons
Note that the update checker will use icons from the installed version, not from the VCS repository.
Adds `main` as a possible default branch name to invoke `$this->getLatestTag()` inside of `Puc_v4p11_Vcs_BitBucketApi::chooseReference()`.
Previously, only branches named `master` inherited this special behavior. With more VCS providers opting for an inclusive default branch name, this commit adds `main` as a default branch name configuration.
Related to #422.
The update checker will look for a `master` branch by default, but new repositories use the name `main` instead, and it is technically possible to use any branch as the default branch. So while you don't *have to* set the branch name, it's probably a good idea to always do that.
Apparently, the "/src" subsection of the BitBucket API doesn't do well with branch names that contain slashes. urlencode() doesn't help. See #409 for the initial report.
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.
Yahnis Elsts
d79
Seaton Jiang
Aleks Moroz
Tim Wiel
Geoff Thibeau
Marco Rocca