A custom update checker for WordPress plugins. Useful if you don't want to host your project in the official WP repository, but would still like it to support automatic updates. Despite the name, it also works with themes.
wp plugin status, wp theme update, and so on. This just triggers the existing scheduling logic, so if you run multiple commands in very quick succession, PUC won't check for updates every time. See #558.Ui class (YahnisElsts\PluginUpdateChecker\v5p3\Plugin\Ui) sometimes did not load correctly if multiple active plugins/themes were using different versions of PUC.upgrader_process_complete callback.phpcs.xml from exported archives. Props to @szepeviktor.Debug_Bar class exists but Debug_Bar_Panel does not. See #543.Creation of dynamic property YahnisElsts\PluginUpdateChecker\vXpY\Plugin\PluginInfo::$example is deprecated.//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.
);
//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
);
Api::RELEASE_FILTER_ALL, you can also use Api::RELEASE_FILTER_SKIP_PRERELEASE to filter out pre-releases.wp_strip_all_tags() instead of strip_tags() when available. Supposedly, it's better at stripping the contents of <script> and <style> tags.main branch is now treated as a default branch (in addition to master).use YahnisElsts\PluginUpdateChecker\v5\PucFactory;
$myUpdateChecker = PucFactory::buildUpdateChecker(
'https://example.com/info.json',
__FILE__,
'my-slug'
);
v5 in the namespace with v5p0.readme.txt from a remote BitBucket remote repository to see if it has a Stable tag header that points to a valid tag. This makes it possible to avoid some unnecessary HTTP requests and may improve performance for your users. Example:
use YahnisElsts\PluginUpdateChecker\v5p0\Vcs\BitBucketApi;
$bitbucketPluginChecker->addFilter('vcs_update_detection_strategies', function($strategies) {
//Don't look for a "Stable tag" header in readme.txt.
unset($strategies[BitBucketApi::STRATEGY_STABLE_TAG]);
return $strategies;
});
STRATEGY_LATEST_RELEASE
STRATEGY_LATEST_TAG
STRATEGY_STABLE_TAG
STRATEGY_BRANCH
preg_match(): Passing null to parameter #2 ($subject) of type string is deprecated. It could be triggered if the update metadata URL did not include a path.assets subdirectory. Props to @timwiel for the initial implementation._).main branch will now be treated as a default branch (in addition to master).lastRequestApiErrors property that could prevent certain update errors from being reported.buildFromHeader($filePath, $args) that lets you specify the repository URL in the plugin header and set other update checker arguments using an associative array. Example:
/*
Plugin Name: Example Plugin
Description: Lorem ipsum
Version: 1.0
GitHub URI: https://github.com/foo/bar/
*/
//...
$updateChecker = Puc_v4p10_Factory::buildFromHeader(
__FILE__,
array(
'slug' => 'plugin-slug-here',
'checkPeriod' => 12,
'optionName' => 'abc-custom-option',
)
);
.999.access_token query parameter to using the Authorization HTTP header. This should stop GitHub sending you email notices about authentication via URL query parameters. Props to @jccit for the initial implementation.first_check_time (full name: puc_first_check_time-$slug). It's passed one argument that is the calculated Unix timestamp of the first update check. Return a new timestamp to make the first check happen at a different time.
//Usage example:
$updateChecker->addFilter('first_check_time', function($unusedTimestamp) {
//Always check for updates 1 hour after the first activation.
return time() + 3600;
});