How to Install WordPress Plugins Directly From Github

It’s amazing how much WordPress code is available on github. Many developers choose not to place their plugins on WordPress.org for one reason or another, but this makes their code less convenient for others to find. Using a plugin from github traditionally requires you to visit github, search for the plugin, download the zip file and upload it to your site to install.

An Easier Way to Find and Install WordPress Plugins Hosted on github

Paul Clark has created a plugin called Github Plugin Search that will allow you to access and install WordPress plugins directly from your dashboard. He found a way to connect the github code search API to the WordPress plugin installer API. Here’s a quick demo of how this works:

How does the plugin detect WordPress plugins hosted on github?

Intrigued by the idea, I tested the plugin and checked in with Paul to find out how the plugin is able to detect WordPress plugins hosted on github. He replied:

Github’s code search API is fairly new (like… it’s still in preview. You have to send a special header just to access it.). They don’t *exactly* provide enough power in their search to truly query for WordPress plugins or to aggressively search the contents of each individual plugin.

To get around their limitations (limits on number of queries, no ability to match exact text like “Plugin Name”), I’m using a combination of two searches, comparing the results, and then filtering down to repositories I’m confident are installable WordPress plugins.

Paul outlined three requirements a repository must meet in order to be found by his github search plugin:

Be a PHP file

Be in the top level of the repository

Have a comment block at the top of the file that matches a WordPress plugin header, with “Plugin Name:” and “Plugin URI:” in a comment block at the top. (This plugin header format is pretty unique — no other PHP systems I know of follow the same format.)

Right now, the plugin full-on replaces the search with results from github. It’s not such a big deal because of the github wp-plugins mirror, but Paul would like to add an option to toggle between wordpress.org and github results in the future.

Example results from searching github

Currently, the results returned are very basic, but Paul said that this is due to working within the confines of the API in preview:

When the Github API comes out of preview, I expect to be able to make results more accurate. Right now, logged in users can only make 20 queries every few minutes. All their other APIs allow 5000. I expect they’ll change it over when it’s final. When they do, the plugin could go crazy getting exact details on plugin files, running checks, and providing richer data from the readme and screenshots.

How Can Users Get Updates For New Stable Versions of Plugins Hosted on github?

I asked Paul if users would still be able to get updates for their plugins if they install from github. This is imperative, because a user wouldn’t want to unknowingly exclude himself from future updates. “The WordPress update API works based on the plugin name, not the source,” Paul explained. “So, if a user were to *install* wp-seo from Github right now, updates from wordpress.org would still work.”

Paul wrote a plugin a year or so ago that updates plugins from Github, Bitbucket, or generic Git repositories (public or private), if the URL is mentioned in the plugin header. It works nicely for him on client sites but in the current version of the Github Plugin Search he has it turned off. He outlines his concerns and the reasons why:

In the current update plugin, the Git URL is set in the header. If all plugins are going to update, I need to generate and store that information for each plugin installed.

The current updater updates when a new version is tagged in Github. Many WordPress developers aren’t in the habit of doing that (it’s the Git way of marking a new version, not the WordPress way), so to work with all plugins, I’d need to modify it to get the version number from the remote readme file. It’s possible to do that, just takes some time.

If the update system is going to be replaced, users should also probably get a user interface to show them which plugins that’s happening for, and allow them to enable or disable it. There’s no reason, other than time, that those concerns couldn’t be resolved in the future.

The Future of Github Plugin Search

So as you can see, the plugin is still a work in progress but a very solid proof of concept so far. Paul plans to continue improvements to the plugin. In the future he may add in the fork and star count for the github repos in order to provide more data for users when selecting plugins. He’s created a list of enhancements that may come further down the road.

If you’d like to fork the Github Search Plugin or suggest changes, check it out on github or get in touch with Paul via Twitter.

Think of it a lot like the Apple App Store and the jailbroken Cydia repositories on iPhones. If you install things from elsewhere, well, you have no form of security. Great for power users and people who can read and evaluate code, but pretty much useless for anybody else.

When you combine this with GitHub, well, the implications are terrifying. With a minor amount of effort, one could create scripts to create github accounts, fork legitimate plugins, insert a couple lines of malicious code, and thus flood the search results with malware intended specifically for this case. Each of these steps is easily scriptable, and can be done without even installing “git” on your computer, thanks to github’s easy forking and editing.

For something like this to be useful, it needs verification and authenticity. It needs a way to eliminate the forks and the false results and to confirm authorship. None of that is in github, at present.

@Otto – I absolutely agree. Even though it is a plugin for power users, and I don’t think Github would be as fruitful for malware as Google, security and authenticity are top priorities.

Github does allow for quite a few options by default: Forks can be excluded, and search results can be filtered by a minimum star count, watch count, or fork count.

The plugin was already excluding all forks by default. Based on your input, I’ll require a minimum star count as well. At a minimum, that will at least require *some* users see *some* value in search results.

That, of course, does not enforce a standard of validated authenticity. I think there is an excellent model for creating that, however, in the Mac package manager Homebrew. Essentially, a list of authenticated repositories is managed in the homebrew repo, and users submit updates via pull request.

Github allows search to be whitelisted by either owner or repository, and users could add their own sources in an admin interface.

This is interesting – but I agree that it is absolutely essential to have the option to switch between WordPress.org and GitHub. I also agree there needs to be a good way to limit the results of the search. Even though WordPress.org is not a perfect model for ensuring plugins follow coding guidelines, there is a system that keeps out most of the chaff. I would like to see them jettison plugins that have not been updated in years(!) – but the same is true on Github. There are going to be orphans that no longer have an active community that turn up in a search if there isn’t a way to set criteria for your search. Yes, you should check the details before you install anything from anywhere – but still – setting criteria would lower the overhead in search.

Actually – I guess I’m preaching to the choir on the criteria issue – that should be a core feature of plugin and theme search on the admin dashboard.

@Mike Dunham – Agreed. I have a selector to switch between wordpress.org and github.com next on my list. It should also include an option to search within a GitHub username.

After adding a minimum star requirement last night, I also added links to view details on the Github repo page or author profile, and now display the author avatar as well. That gives a stronger sense of who is publishing what.

I tend to agree with @Otto too. It is a good idea, but you definitely need to build in security for it to work properly.

Apart from that, I host all my plugins on both the WordPress Repository and Github. But what’s on Github is “stable” beta as I like to call it and on the official Repository I only host the latest stable versions.

So for normal users I would not recommend to download my plugins via Github.

There’s also Code for the People’s ‘External Update API’ (https://github.com/cftp/external-update-api), which doesn’t help with the initial search/installation, but once you have installed a plugin (or theme) from GitHub it allows you to get updates from there (even if the code is in a private repo). It’s extensible so you can add your own non-GitHub sources too.