GitHub Updater now gives some feedback when the API responds with an error. What I’ve done is capture the HTTP error code and add that to an admin_head hook.
I’ve also included some data if the error is the result of banging against GitHub API’s rate limit for unauthenticated accesses.
As these are HTTP response codes it’s pretty simple to figure out. A 401 means that the authorization is incorrect.
For Bitbucket repos this can mean not having read access to the repository or having an incorrect user/pass entered in the Settings.
For GitHub repos it can mean using an Access Token for a public repository or having the incorrect Access Token for a private repository.
A 403 error usually means that you have surpassed GitHub API’s rate limit for unauthenticated access of 60 per hour or you have not included an Access Token for a private GitHub repository.
If you have knocked up against the rate limit, the error will tell you when your rate limit will be reset.
So just a couple of weeks later and I now have a logo for GitHub Updater.
I worked with Mark at @LogoMajestic and I must say after a few initial concepts from LogoMajestic I sent them a quick sketch of my concept and they nailed it in the first go round.
I couldn’t be more pleased and I’d recommend @LogoMajestic to anyone.
So here I am being a sponsor for @WordCampSD. I received an email asking for a logo. Oops. I don’t really have one. I was asked for a company name and the only company I belong to is Desert Trauma Surgeons. I’m not a partner so I can’t really use their logo.
That’s when I decided it was time to get a logo for GitHub Updater. Since I’ve never really done this before I put out an issue on the GitHub repo and tweeted.
An enterprising graphics company sent me note via my contact page and we’re starting to get to it. He sent off a couple of concepts and while some were good it led me to think a bit more about what I thought would be representative of GitHub Updater.
A quick sketch in Paper and I think we’re off and running. Here’s my sketch and we’ll see where we get to from here. Can’t wait.
I did contact Bourn Creative and unfortunately we aren’t able to work together on this project. But they are awesome and Jennifer was great. I am currently working with Mark at LogoMajestic who has been very professional and prompt. Another post for the unveiling.
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.
Download the repository (and branch) that you want to install.
Unzip the download.
Rename the download folder as it will likely have some combination of the username-repo-hash/branch as the name.
Compress the newly named download.
Upload via the WordPress ‘Upload Plugin’ or ‘Upload Theme’ interface.
Or you can use the new 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.
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.
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.
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. 😉