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: or GitLab Enterprise:

Extras for GitHub

Support for GitHub Enterprise is also included using a similar header, GitHub Enterprise:
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.

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.

GitHub Updater 4.1.0

GitHub Updater v4.1.0 has been pushed and tagged.

Thanks to My Bug Reporters

First, I need to thank Jeremy Saxey, Matt Redford, and w33zy for their bug reports and help in squishing them. Some bugs are difficult to reproduce as everyone’s installation is a bit different. What this means is that some bugs when a user first installs the plugin may not show up for me.

Using Remote Install

Wow, I’m really blown away as to how useful this is. Installing a plugin or theme from either GitHub or Bitbucket involves several steps that are essentially the same.

  1. Download the repository (and branch) that you want to install.
  2. Unzip the download.
  3. Rename the download folder as it will likely have some combination of the username-repo-hash/branch as the name.
  4. Compress the newly named download.
  5. Upload via the WordPress ‘Upload Plugin’ or ‘Upload Theme’ interface.

Or you can use the new remote install.
plugin remote install
Enter the data and none of the above will be necessary.
Sure if you are trying to install from a private Bitbucket repository you will need to add your Bitbucket username and password in the Settings tab.
Go and play and be sure to share if you find this helpful. Use hashtag #GitHubUpdater.

GitHub Updater and Remote Installation

So GitHub Updater v4.0.0 is out. It includes a huge refactoring and now requires PHP 5.3 or better. GitHub Updater now uses namespacing and PSR 4 autoloading.
I read a recent WP Tavern article and showed me what others are doing in the same space. I was intrigued. WP Pusher has done terrific work in creating a solution to remote installation and updating. I wondered, how difficult would it be to add remote installation of WordPress plugins or themes to the existing framework. It turns out, not that difficult.

GitHub Updater and Remote Installation

What’s next for v4.1.0?
The develop branch has a working method of remote installation of both public and private GitHub or Bitbucket repositories.
I must confess, the hardest part was getting everything in the Settings API functioning. I used some code from WordPress Zero Spam by Ben Marshall and borrowed a couple of lines from TGM Plugin Activation by Thomas Griffin.
I was quite familiar with WordPress Zero Spam; I’ve been a contributor on GitHub. Ben has done a nice job of creating a modularized approach to coding a tabbed Settings interface.
Thomas and Gary Jones have done a great job with TGM Plugin Activation and I highly recommend it when other plugins are required for any other single plugin to function. I am very familiar with Gary’s work as he has helped tremendously with GitHub Updater.
After setting up the tabs in the Settings page I was able to simply create the correct endpoint for GitHub and Bitbucket. I thought allowing for private repository remote installation my prove more difficult but a couple of modifications in other parts of the plugin made this relatively painless. Well, painless once I figured out what I needed to do and where in the existing code I needed to do it. 😉
Thanks to a couple of lines from TGM Plugin Activation I could figure out what I needed to do to create a new instance of both the Plugin_Upgrader and Theme_Upgrader for remote installation.
So now it’s all wrapped up in a nice little package. Remote installation and automatic updating in GitHub Updater. So go grab a copy from the develop branch, or just change the branch designation of your existing copy to be automatically updated, and try to break it. If you do be sure to put an issue up on GitHub and let me know. Remember to change your header back to GitHub Branch: master unless you want to stay on the develop branch.
I must say this is all pretty slick. It certainly makes downloading a repo from GitHub, renaming it correctly, and then uploading it a single click experience.
Remember, if you’ve installed a private plugin or theme, you must visit the settings page and enter the appropriate credentials, GitHub Access Token and/or checkbox to ensure that automatic updating works.
Please let me know your thoughts.

Refactoring and Autoloaders

There are always a couple of plugins that require either constant care and upkeep or you just want to keep making them better. I have 2 plugins that I put more care and feeding into than others. These are GitHub Updater and The Events Calendar Category Colors. Both of these projects are free and open sourced. They both live on GitHub and this allows for both of these plugins to be much better than I, alone, could make them.

GitHub Updater

I’ve written a number of posts lately about GitHub Updater so let me just say that recently I’ve been get PRs for translations and I think it’s very cool. I continue to refactor GitHub Updater and requiring PHP 5.3 is probably not a big deal as most users of it developers and are probably already using at least this version. Eventually I’ll add namespacing support, when I figure it out. 🙂

The Events Calendar Category Colors

The Events Calendar Category Colors is an add-on plugin to Modern Tribe’s The Events Calendar. I’ve been very fortunate to have lots of help and assistance from Modern Tribe and especially from Barry Hughes. Modern Tribe develops The Events Calendar (TEC) on GitHub. This allows be to see what’s coming and what I see coming is a major refactoring of the plugin in anticipation of PSR 4 autoloading. This is clearly in anticipation of WordPress moving their minimum PHP requirement to 5.3. I can also see that namespacing is coming.
This has spurred me to figure out how users of current and past versions of TEC will continue to use The Events Calendar Category Colors without fatal errors. Modern Tribe has used a method of creating class aliases, mostly so they don’t inadvertently break anything. In looking at this I found that I could use a similar method to support their upcoming release and previous releases. While Modern Tribe isn’t yet using namespacing, I’ve decided to use namespacing. I’ve done this mostly because I wrote a generic Autoloader class and to use it in multiple plugins I would either need to rename the funtions to be unique or I could just create a unique namespace for each plugin. Because of this The Events Calendar Category Colors will require at least PHP 5.3. Of course, Barry re-wrote it better. 😉
Using spl_autoload_register is a great function to simply your code and hopefully make it more memory efficient by only loading classes when needed. As such, more complex plugins will benefit from this more than simple plugins. Technically, spl_autoload_register is in PHP 5.2.
So here I am working on refactoring The Events Calendar Category Colors to run in a namespaced environment. You can follow my progress as development is on GitHub. As usual Barry’s already been a great help and sounding board.
There is a side benefit to keeping this plugin refactored and running as efficiently as possible. It makes it much easier to eventually drop it in to The Events Calendar core, if Modern Tribe has such thoughts. 😉