Previously, triggerUpdateCheckOnce() was attached to a transient filter, but that's no longer the case. Now it's passed directly to WP_CLI::add_hook().
However, it still takes and returns a value. WP-CLI documentation says that the `before_invoke:<command>` hook takes one argument and acts as a filter.
PUC already used `upgrader_process_complete` to remove hooks when the plugin version it was part of was deleted during an update. However, that did not catch more obscure situations, such as apparently being called from an unrelated AJAX request while the host plugin version was being deleted (a user sent a stack trace where it seems that was what happened).
When a plugin update overwrites PUC with a different version of PUC, the hook callbacks registered by the old version can trigger fatal errors when they try to autoload now-deleted PHP files. Normally, PUC avoids this by using an `upgrader_process_complete` hook to check if one of its files still exists, and removing the hooks if the file is missing.
However, it appears that WP Last Modified Info has its own `upgrader_process_complete` callback that runs earlier. That callback tries to download plugin metadata, which indirectly triggers some PUC hooks, and leads to the fatal error(s) mentioned earlier.
Fixed by extracting the relevant part of `upgraderProcessComplete` to a separate method and registering that method as a callback for the same hook, but with an earlier priority (1 instead of 11). It appears that WP Last Modified Info uses the default priority: 10.
This can happen when PUC is configured to use a branch (as opposed to tags or releases) and it fails to retrieve the main plugin file from the repository, e.g. due to API rate limits. Then it can't get the "Version" header from the main plugin file.
See #526
Update metadata can include additional, arbitrary fields such as request statistics, licence information, and so on. This data was stored as dynamic properties on Metadata subclasses, which triggered a deprecation notice in PHP 8.2. Fixed by explicitly storing dynamic fields in a new protected property and adding magic methods to access/modify those fields.
Fixes#536
The main functional change is that PUC will now use shorter HTTP request timeouts when not running inside a Cron task. This is to comply with the WP VIP coding standard that strongly recommends a maximum timeout of 3 seconds.
Prompted by #107
When setting
$myUpdateChecker->setBranch('main');
the setting enableReleaseAssets was ignored. But since on newer versions "main" is the default (and not "master"), it should allow it.
array_filter keeps the index, so if the asset matching has index 1, an array with key 1 is returned. However, further down, $matchingAssets[0] is always used. This will then fail. Using array_values after array_filter resets the indexes on the array from 0, solving the problem.
The filter is applied when trying to get the latest release from a VCS repository. Inspired by #506.
Example of filtering releases by the version number:
```php
//Allow only beta versions (e.g. for testing).
$updateChecker->getVcsApi()->setReleaseVersionFilter(
'/beta/i', //Regex for the version number.
Api::RELEASE_FILTER_ALL, //Disables the default filter(s).
30 //Max number of recent releases to scan for matches.
);
```
Alternatively, you can use a callback to implement custom filtering rules.
```php
//Set an arbitrary custom filter.
$updateChecker->getVcsApi()->setReleaseFilter(
function($versionNumber, $releaseObject) {
/*
Put your custom logic here. The $releaseObject variable contains
the release data returned by the GitHub/GitLab API. The format
will vary depending on which service you're using.
*/
return true;
},
Api::RELEASE_FILTER_ALL
);
```
Setting a new filter will override any previous filters, so you can't add a regex-based version filter and a custom callback at the same time.
The GitLab release asset implementation was unnecessarily complex and did not match the coding style of the rest of the project (it was provided by an external contributor, and I didn't feel like rewriting it at the time). With the recent change of requiring PHP 5.6 as the minimum version, it's now possible to extract most of the asset logic into a new trait.
This also provided the opportunity to add an undocumented way to *require* that a release have assets:
`enableReleaseAssets('optional-regex', Vcs\Api::REQUIRE_RELEASE_ASSETS)`
Prompted by #505
The notice: "Passing null to parameter #1 ($string) of type string is deprecated". This could be triggered because some update fields can be null, like the upgrade notice field.
This fixes or explicitly ignores most - but not all - coding standard issues that are reported when running PHP_CodeSniffer with the basic WordPress ruleset and the WordPress-VIP ruleset.
Notably, one of the issues that remain is the request timeout for update requests and VCS API requests. The current default is 10 seconds, but the WordPress-VIP standards appear to require 3 seconds or less. Personally, I'm not sure if that low limit is appropriate for requests that are intended to mostly run in Cron jobs.
This means that previously cached updates can't be loaded by this version, but that should be fine. The cache will just get updated the next time PUC checks for updates.
Technically, this is not necessary because that part of the library hasn't really changed, but let's use the same version number everywhere for consistency.
^ Except dependencies like Parsedown.
The readme is now out of date. The legacy version of Parsedown was removed because we no longer need to support PHP versions older than 5.3. The stub file that loads ParsedownModern.php stays in place because it has the "class_exists" check.
Example:
```
$bitbucketPluginChecker->addFilter('vcs_update_detection_strategies', function($strategies) {
//Don't look for a "Stable tag" header in readme.txt.
unset($strategies['stable_tag']);
return $strategies;
});
```
To make this possible, the chooseReference() method was refactored into something that more closely resembles a "chain of responsibility" pattern. Instead of a tree of "if" conditions, it now gets an array of callables from another method, and it calls each of those in order until it gets a non-empty VCS reference.
You can filter this array to remove specific strategies, or even to add your own. Note that the item order matters.
Required PHP version was increased to 5.4 because some "strategies" take an argument and some don't, and I would rather just use closures for that than something more complex.
Coincidentally, testing this change revealed a bug where the HTTP filter name was not initialized correctly: it was missing the $slug. That should also be fixed now.
Prompted by #378
In the (unlikely) case where the update metadata URL does not include a path, the getVcsService() method could previously trigger a deprecation notice like "preg_match(): Passing null to parameter #2 ($subject) of type string is deprecated". This is because parse_url() returns NULL when the specified component is not present.
Fixed by always casting the $path to string. The VCS detection code doesn't care about the difference between "empty path" and "no path" - it should correctly return NULL (= no VCS host found) anyway.
Also, let's cast $host to a string as well to avoid another potential notice if the URL somehow has a path but no domain name.
Initially reported in #499.
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.
Yahnis Elsts
Franky Van Liedekerke