Refreshing Cache

Use the Refresh Cache button in the Git Updater Settings Page screen and all the cached data will be deleted and the API will be queried again. This may cause timeout issues against the API, especially the GitHub API which only allows 60 unauthenticated calls per hour. Please set a Personal GitHub Access Token to avoid these timeouts.

API errors, such as authentication errors caused by missing or incorrect tokens, will be cached for 60 minutes. If you have WP_DEBUG set to true, an error log entry specific to the repository will be entered in debug.log.

Under normal circumstances, the cache expires and is refreshed every 12 hours.

Settings Tabs for Git Hosts

Settings tabs for all git hosts are created dynamically. By default you will have the general Git Updater and GitHub tabs. This is because the Git Updater tab is for general settings and since this plugin has the appropriate GitHub Plugin URI header the GitHub tab displays.

If you have the appropriate Git Updater API plugin(s) installed and active along with appropriately configured plugins or themes for Bitbucket, GitLab, Gitea, or Gist, then those tabs will also display. You will be able to add/change your credentials here. Deactivating the API plugin may cause your credentials to be reset and require re-entry in the appropriate settings tab.

Your correctly configured plugins and themes will display in their respective tabs.

Private Repositories

Private repositories that require some sort of additional authentication or acknowledgment will show up in the Settings page.

GitHub Private Repositories

In order to specify a private repository you will need to obtain a personal access token. The access token must have read privileges for repo and read:packages. Once you have this, simply add the token in the GitHub Settings tab. If a plugin or theme will not work with your personal access token; add the appropriate access token in the Install tab.

If your private repository is owned by an organization you must obtain a personal access token from the organization, even if you personally have access to the repository.

Leave this empty if the plugin or theme is in a public repository. If your personal access token allows read access to a private repository, that repository will not display as needing an access token.

GitHub – Fine grained personal access tokens

GitHub now has a fine-grained personal access token. You may set these for individual repositories and they will be much more suited to share with others.

You should choose a specific repository and then you only need repository permissions for Contents – Access: Read Only, and Metadata – Access: Read Only.

Bitbucket Private Repositories

Add your personal Bitbucket username and application password in the Bitbucket Settings tab or in the Install tab. In order to authenticate with the Bitbucket API you will need to have at least read privileges for the Bitbucket private repository.

After entering the Bitbucket Username and Password, Git Updater will automatically convert those values to a Bitbucket Pseudo-Token and save it. The Pseudo-Token is simply the username:password as a string. There is a colon : separating the 2 values.

Do not include your username or password in the plugin or theme URI.

WordPress and PHP Requirements

There are two optional headers for setting minimum requirements for both WordPress and PHP.

Use Requires at least: to set the minimum required version of WordPress needed for your plugin or theme. eg. Requires at least: 4.6

Use Requires PHP: to set the minimum required version of PHP needed for your plugin or theme. eg. Requires PHP: 5.6

Release Assets

An optional header is available for use if your plugin or theme requires updating via a release asset.

Use Release Asset:. eg., Release Asset: true.

Your release asset filename might be generated automatically. While there is no restriction on what the release asset may be named, if there are more than one release assets per release, then naming restrictions will be required in the following format. The asset name used for updating must be in the following format, $repo-$tag.zip.

Example, $repo-$tag.zip where $repo is the repository slug and $tag is the newest release tag, example test-plugin-0.7.3.zip.

There is support for GitLab Build Artifacts which may be used as a release asset. You must also add the header, GitLab CI Job:, with the build job name.

Branch switching will not be available for repositories using release assets to update.

You must tag your releases to use this feature.

Primary Branch

An optional header is available for use if your plugin or theme has a primary branch other than master. Historically a new repository created in GitHub was created with a master branch. This has changed and new repositories are created in a main branch. You must add the Primary Branch: main header to your repository’s main plugin file or theme’s style.css file or the API will respond with a 404 error when checking.

The default is still master and for historical reasons this has been more consistent among GitHub, Bitbucket, GitLab, etc. If you, as a developer, wish to use another branch as your production-ready branch, as in git-flow, you can now set this via the Primary Branch header.

Example, Primary Branch: main if you have changed your repository to use main instead of master.