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.
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.
I’ve been doing a lot of tweaking to GitHub Updater. The plugin now runs on the front-end and only for privileged users. This allows for a couple of things.
- It makes less overhead for the non-admin user.
- Second it allows for update services to do their thing.
I’ve tested with several update services and iThemes Sync works great out of the box. I’ve been told MainWP works and ManageWP works. ManageWP does not yet have support for child themes but I’ve been told it’s in the works. I’ve been told mixed things with InfiniteWP and I’m unable to test well against it.
Classes are autoloaded using
spl_autoload_register and I’m now using Parsedown to render the change logs. Additionally, efficiency gains are achieved by only parsing remote file headers and saving those headers to transients. I’ve also added 2 new headers (
Requires PHP and
Requires WP ) to set the minimum requirements of both PHP and WordPress for your plugins or themes. If the minimum requirements aren’t met on the user’s system then your plugin or theme will show an update.
One of the biggest changes is a Settings Page. No longer are GitHub Access Tokens or Bitbucket passwords required to be stored within the repository. They can be added after plugin or theme installation. This should help with security.
Update Bitbucket Private Repositories
One of the most glaring bugs was my inability to update Bitbucket private repositories. Somewhere along the path to add Settings API functionality or more precisely improving HTTP Authentication headers only for the proper plugins or themes, it seems that Bitbucket private repositories now update correctly.
If anyone’s interested in working on a Gitlab module please ping me.
In Part 1, I tried to describe some of the why and a little of the how I’ve gotten to this point with GitHub Updater. In this point I’ll try to go into a bit about how the plugin works.
The basic premise and design of GitHub Updater is to be very lightweight to both the developer and the end user. For the developer, inclusion of only one or two lines of code in the plugin or theme header will allow it to get automatic updates via GitHub Updater. All the end user needs to do is install and activate (or network activate) the GitHub Updater plugin.
GitHub Updater is even smart enough to allow for plugins to be hosted on WP.org and get updates from WP.org as long as the branch header is
master. If the developer wants to update from GitHub all they need to do is change the branch header to something other than
master. I use this for development by designating
GitHub Branch: develop on my development site. Please refer to the README for a better explanation.
When the branch is
master and there are tagged releases, these tagged released are preferentially used for updates. When the branch is something other than
master, tagged versions are ignored and the specified branch is used during the update.
In the plugin’s evolution I think I’m using some better OOP practices. As such, as I search though all the plugins and themes in the user’s installation I parse out those that don’t have the requisite header. When I find a plugin or theme that has the appropriate header, either
GitHub Plugin URI,
GitHub Theme URI,
Bitbucket Plugin URI, or
Bitbucket Theme URI what happens is that the URI is parsed and data from the local plugin is placed into a class object. As you’ve no doubt just noticed the GitHub Updater does also works with Bitbucket hosted code too.
After gathering the local data, the plugin reaches out to GitHub via the GitHub API to get the remote info. At this point there is lots of transient setting and getting so the GitHub API doesn’t get hit too frequently. This is necessary because GitHub’s API only allows 60 unauthenticated requests per hour. More than 60 requests per hour yields a 403 error. Bitbucket’s API doesn’t seem to have this limitation, but the results are cached nonetheless.
Each API class, so far just GitHub and Bitbucket, is written as an extender class. Doing it this way should allow for adding additional API classes for additional git repos in a more logical fashion. Think Gitlab.
CHANGES.md file is also parsed, if present, to add into the View Details screen. At this time parsing a standard
readme.txt isn’t done, but it’s certainly something on the horizon. I’ve also created a pseudo-rating based upon the number of stars, forks and issues the repo has.
The updating is hooked into WordPress’ core methods, as is renaming of the downloaded plugin/theme update. So far so good and GitHub Updater just works in WordPress 4.0beta.
I’m sure there’s probably another post, Automatic Plugin & Theme Updating from GitHub – Part 3, coming.
About 10 months ago I decided to scratch an itch. I was running 3 or 4 different WordPress websites, including this one. I was also playing around customizing these sites by creating some one-off plugins and child themes. At the time I was doing a lot of cowboy coding on my own domains. Mostly because I didn’t know better. Developing in localhost has been an amazing boost in productivity.
I have to mention this because this is not my day job. In fact, my day job keeps me incredibly busy and usually I end up coding at night and in off hours. For those that don’t know, I’m a trauma/acute care surgeon. Currently I’m also the Chief of Staff of one of our local hospitals. It’s not like I already didn’t have enough free time.
So I was creating a number of simple plugins that I really didn’t think were either good enough or appropriate for the WP.org repository. As such, when I wanted to use them on different sites I would FTP them up after writing them and then I’d have to do it all again after updating them. I decided it was time to figure out how to hook into WordPress’ automatic updating. At the time, the most popularly used method was Joey Kudish’s WordPress GitHub Plugin Updater.
As I was looking into the code the first thing I felt myself wanting to do was to make the code into a plugin so I didn’t have to put so much extra code into the plugins to be updated. Later I found another couple of projects that did either plugin or theme updating.
Initially I was able to modify one, Codepress’ GitHub Plugin Updater, enough so that I not only had a working plugin updater, but I had managed to parse the GitHub URI of the plugin’s repo to the point that no other settings were needed inside of the plugin that’s being updated other than a single header line.
Around that time Kudish’s project wasn’t getting a lot of updates and in one issue that Gary Jones had created, I referred him to my project. Now you have to know, I had no idea at the time who Gary was. Boy do I now. Gary forked my project and the next thing I noticed were several pull requests that made the code look so much better and work so much more efficiently. Gary was incredible. He gave invaluable feedback without telling me how silly it was do things the way I was and made me think about WordPress Coding Guidelines, at least a little bit.
At this point plugin updating was fairly solid and next up for me was updating for themes. There were 2 projects that did theme updating, one from UCF’s Theme Updater, and one from Seth Carstens, part of his Whitelabel Framework, which improved upon UCF’s work. Currently theme updating is working as well as it is in a very large part due to Seth’s help.
Originally I had created 2 plugins one for updating plugins and the other for updating themes. After both were functioning, I decided to combine them into a single plugin that I call GitHub Updater.
Along the way Paul Clark provided immense help and support by showing me both why and how I should do things one way instead of another. Paul even created his own version, Git Plugin Updates.
What I’ve hoped I’ve created in GitHub Updater is a plugin that not only scratches my itch, but also makes plugin and theme development and updating simpler for many other developers within the WordPress community.
Next up, Automatic Plugin & Theme Updating from GitHub – Part 2.
So I decided that I really didn’t need to tag releases of child themes that only I am using. Probably not best case usage but I got tired of pushing tags for minor CSS changes.
So I opened the terminal and
cd to the appropriate local git directory that has a remote on GitHub.
Then it’s a simple command.
git push --delete origin tagname
tagname is the tag version number.