Surgical Diversions

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.

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. 😉