Dr Fragen in the operating room

GitHubUpdater

  • The need or desire to use a personal remote management service makes a few assumptions.

    1. It assumes that the developer has personal or client projects that are under version control on a system like GitHub, Bitbucket, GitLab, or some other system.
    2. It assumes that these projects are utilized on multiple sites.
    3. Lastly, it assumes that the developer would like a simple method of pushing updates to these multiple sites.

    GitHub Updater allows for updating of plugins and themes that are developed outside of the official WordPress repository. Often these projects reside in GitHub, Bitbucket, or GitLab. Updating these repositories to a handful of sites usually involves visiting that site’s dashboard and updating the plugin or theme in the usual manner. The difficulty arises when you’re managing the same plugin(s) or theme(s) on many, many sites.

    Current State of Updating

    You don’t want to spend time visiting each site to update these repositories. It takes too long and quickly becomes inconvenient. It’s much simpler to use a remote management system and push updates to multiple sites. There are several commercial plugins and services to accomplish this. Among them are iThemes Sync, ManageWP, MainWP, and InfiniteWP.

    The problem is that these services were designed only to work with the official WordPress repository and not with GitHub, etc. These plugins all work by showing you that an update is pending and allow you to update all the plugins for a site en masse or all of a particular plugin on multiple sites. Set up of these plugins requires a variable degree of effort and occasional errors can be difficult to troubleshoot.

    GitHub Updater has had the ability to utilize many of these remote management services for a couple of years but it’s always been a bit unstable and difficult to test. Recently much of this instability has been removed by allowing for GitHub Updater’s API calls regardless of the web site visitor’s privileges. However, it still requires someone visit the site to ensure that WP-Cron runs and GitHub Updater maintains current update information.

    Webhook Updating

    GitHub Updater has also been able to utilize a webhook to update repositories too. This method doesn’t require WP-Cron or anyone to even visit the site. Send the appropriate webhook and the repository will update. Personally, I use a webhook to update GitHub Updater on the develop branch on my test site every time a GitHub push is identified. This way I can ensure I’m always testing with the most recent commits.

    Updating via a webhook is a more of a push than a pull. For reference, my idea of a pull would be the site shows that an update is pending and pulls the update from the remote source. A push would be similar to a re-installation of the plugin from the current source. In GitHub Updater’s parlance, it’s exactly like branch switching. If you switch to the same branch it’s simply re-installing with the latest code. There is no version checking in this process.

    REST API Endpoint Updating

    GitHub Updater previously used a admin-ajax.php request to provide for webhook updating. I have finally re-written this to an actual REST API endpoint and it has made the Git Remote Updater possible.

    Currently there are 3 endpoints.

    1. repos – returns a listing of the sites GitHub Updater enabled plugins and themes along with their current branch.
    2. update – processes the actual webhook request.
    3. test – Yeah, I just left it in. 馃檭

    Git Remote Updater

    Recently I’ve written a plugin to facilitate your own personal remote management system, Git Remote Updater. Git Remote Updater will allow you to update individual repositories on multiple sites or all the repositories in a single site with a single button click.

    How It Works

    Functionally, the Git Remote Updater Plugin simply sends a webhook as an HTTP GET request to the site. This allows GitHub Updater to update the repository. The best part is that Git Remote Updater is able to send multiple webhook requests with a single click.

    Git Remote Updater only needs the site鈥檚 URL and API key from GitHub Updater to enter into the Git Remote Updater Settings tab.

    GitHub Updater Site Data
    GitHub Updater Site Data
    Git Remote Updater Settings
    Git Remote Updater Settings

    This site specific data is all that is necessary to validate with the site and update the repositories. This data only needs to be updated if the site’s Remote Management API key changes.

    The API key is easily reset and only functions on the update endpoint to authorize an update on the site and one the repos endpoint to collect repository data.

    There is a REST API endpoint that returns the site’s GitHub Updater enabled plugins and themes along with data regarding the installed branch. The second REST API endpoint is for updating. It utilizes data from the JSON file to form a correct webhook for updating. Both of these endpoints require an API key for authentication.

    In order to ensure that this remote updating works, updating must work on the site’s dashboard too. This means that any access tokens or username/password data must be correctly saved on the remote site. I have found that utilizing the Git Remote Updater works best on a local development environment.

    Update by Repository or by Site

    There are 2 ways to update in Git Remote Updater. You may update individual repositories on multiple sites or you may update multiple repositories on an individual site. A dropdown menu conveniently switches between the two options.

    Git Remote Updater by Repository
    Git Remote Updater by Repository
    Git Remote Updater by Site
    Git Remote Updater by Site

    Feedback

    An example of the type of feedback supplied is below.

    Git Remote Updater Feedback
    Git Remote Updater Feedback

    Functional Differences

    Git Remote Updater doesn’t seek to provide feedback about the update status of a particular plugin or theme. It simply forces an update based on the installed branch of the remote repository. This is functionally equivalent to a reinstallation or branch switch to the same installed branch of the repository.

  • GitHub Updater and Gitea

    Gitea is the new kid on the block for creating a self-hosted git server. Gitea is written in Go and is highly performant with very low overhead. In fact, Gitea is so efficient you can run it on a Raspberry Pi. There鈥檚 another post coming about that. 馃槈

    As with most integrations of new git servers into GitHub Updater it all starts with an issue and a user willing to help. In this case, the user was Marco Berchart.

    Over the years, I鈥檝e continued to refactor GitHub Updater to become more OOP based and adding Gitea support definitely shows that this was the way to go. Adding support for Gitea was far and away the simplest integration yet. Much of this has to do with API closely following the GitHub API.

    Marco was kind enough to start by creating 聽a PR and we were able to work on a branch until it was complete and able to be merged. There is a demo site at https://try.gitea.io where a test account can be created. There is no guarantee any sort of persistence and don鈥檛 expect your data, or possibly even your user, to be around long term. Marco was able to provide an account on his Gitea instance for me to test. I couldn鈥檛 have finished the integration with this access.

    Since then I have figured out how to install Gitea on a Raspberry Pi. I’ve actually done the process several times and even updated both Go and Gitea. It makes testing much easier for me and it makes setting up your own local git server for less than $100 simple.

  • GitHub Updater & GitLab

    GitLab Support

    I’ve finally been able to add support for GitLab in the GitHub Updater v4.5.0. Additionally, support for GitLab CE and GitLab Enterprise are also included. All that’s required is an additional header with the base URI for the GitLab server. As an example, GitLab CE: https://gitlab.example.com or GitLab Enterprise: https://gitlab.example.com.

    Extras for GitHub

    Support for GitHub Enterprise is also included using a similar header, GitHub Enterprise: https://github.example.com.
    Support for updating from GitHub assets is also included if an asset exists for a tagged release. It will be preferentially used for the update. Using an asset’s URI for the remote installation of a plugin or theme will also function as expected.

    Under the Hood

    A bit of refactoring has been done as well. An abstract class API has been created to simplify the structure of all the git server API classes. Additionally a class Messages has been created to hold admin notices.
    The class Base has been refactored to hold information regarding the added APIs in static arrays for use throughout the codebase.
    I hope everyone likes the changes and updates. As always, if there are problems or improvements, please create an issue on GitHub.
    Thanks.

  • Smash API Rate Limit & More

    So GitHub Updater just received a couple of new features in version 4.3.0.
    At the suggestion of @mlteal, there is now a setting to add a personal GitHub Access Token. You must at least select public_repos. What this does is blast away the limit of 60 API calls per hour and raises it to 5000 API calls per hours. If you need more than than I’ve got nothing more for ya. :smiley:
    At the suggestion of our friends at Pods I’ve added the ability to switch between branches of a plugin. You must ensure that all branches have the appropriate headers otherwise you may find yourself unable to update. :frowning:
    @szepeviktor has been driving me to fix a number of things including now having View details available on the plugins page.