One of the things I love about WordPress is the plugin architecture, as it allows users to contribute and extend WordPress without compromising the sanity and clarity of its core.
Whenever I write a plugin I tend to submit it to the official plugin repo, where it can quickly be downloaded and used by thousands of savvy users. I also often host my plugins on GitHub too; either because I’m still developing them and I’m not quite ready to release them to the world or simply because it might be a client-specific or commercial plugin. In those cases I always feel shorthanded when I see other plugins receive new update notifications and the ones on GitHub have to be updated manually.
However, with some recent code by Joachim Kudish, pushing new releases of these plugins on GitHub has become a lot easier, as it allows me to seamlessly combine official plugins with commercial ones and to update them in one go. Every time I decide to release a new version, I just need to tag the release and the plugin will get a “new release available” message on the user’s admin panel. I have tried it out and it’s fairly easy to setup.
It’s available via a class we must include in the plugin to support GitHub updates. Download it and put the updater.php (source) into the plugin directory that you will want to auto update and make sure that the plugin includes the file:
include_once('updater.php');
The next step is to initialize the class. You can do this by adding:
| if (is_admin()) { // note the use of is_admin() to double check that this is happening in the admin | |
| $config = array( | |
| 'slug' => plugin_basename(__FILE__), // this is the slug of your plugin | |
| 'proper_folder_name' => 'plugin-name', // this is the name of the folder your plugin lives in | |
| 'api_url' => 'https://api.github.com/repos/username/repository-name', // the github API url of your github repo | |
| 'raw_url' => 'https://raw.github.com/username/repository-name/master', // the github raw url of your github repo | |
| 'github_url' => 'https://github.com/username/repository-name', // the github url of your github repo | |
| 'zip_url' => 'https://github.com/username/repository-name/zipball/master', // the zip url of the github repo | |
| 'sslverify' => true // wether WP should check the validity of the SSL cert when getting an update, see https://github.com/jkudish/WordPress-GitHub-Plugin-Updater/issues/2 and https://github.com/jkudish/WordPress-GitHub-Plugin-Updater/issues/4 for details | |
| 'requires' => '3.0', // which version of WordPress does your plugin require? | |
| 'tested' => '3.3', // which version of WordPress is your plugin tested up to? | |
| 'readme' => 'README.MD' // which file to use as the readme for the version number | |
| ); | |
| new WPGitHubUpdater($config); | |
| } |
In your Github repository, you will need to include the following line (formatted exactly like this) anywhere in your Readme file:
~Current Version:1.0~
You will need to increment the version number whenever you update the plugin, as this will ultimately let the plugin know that a new version is available. Once the plugin finds it has an update, it downloads a zip file from GitHub, eliminating the need for git installed on the server.
It used to be the case where this would only work with GitHub public repositories, but about 4 months ago Paul Clark stepped in and started working on support for private repos through Github oAuth tokens. He says it’s functionally complete and I’ll definitely give it a try (Issue #15).
I’m quite excited with this updater class and I think plugin developers should seriously consider integrating it into their workflow because it makes things a lot easier.
I, for one, know I’ve impressed a few clients already.
Ooh, I quite like this one. I had already bookmarked a few options like this, but this solutions actually looks like it the easiest way to implement it. Thanks for sharing!
hey,
Thanks for sharing this 🙂
I’ll be making some updates to the class in the future. It needs some code cleanup and a few things can be simplified about it.
Let me know if there’s anything you’d like to see in there
Nice! I was looking for something like this 🙂 Thanx.
One thing which would put me off this solution for WordPress.org hosted plugin is the fact that any updates from Github will not increase your download count on WordPress.org.
I’d definitely use this for things hosted outside of WordPress.org though. It looks like a great way to implement this functionality.
True about the counters. Thanks for this tip too.
The intention of the class isn’t to work with WordPress.org hosted plugins, but instead to replace that system in specific scenarios only. For example, if you have a plugin that was written for a client or there is some other reason that you don’t want to promote it using the WordPress.org repository, you would be able to host it on Github and use the class to provide auto-updates for the users of your plugin.
I was looking for something like this beautiful post thanx guys
Hi All,
I want to auto update my WP plugins which is not hosted on wordpress.org.
But this script is deleting the current plugin and replaces it with latest one.
Now my problem is my plugin is contain some site specific css changes that user have done according to
His site layout, now what happen if i update the plugin it replace this with latest one so all changes related to css reset. so is there any solution for this?
Or can i do something in that i can only give some specific files only that related to business logic only?
One more thing can i define some specific time like 15 days in that time line user must have to upgrade plugin after that timeline plugin will be deactivated and not work for users sites,
Thanks,
This is great! Thanks for sharing 🙂
A simpler solution only adding a single header to your GitHub hosted plugin is available using https://github.com/afragen/github-updater