Custom WordPress Plugin Update Repository

I have recently been spending a lot of time developing the¬†IssueM plugin for a company I do a lot of contract work for. IssueM is an issue manager plugin for WordPress, to manage issues for online magazines, periodicals, and such. The idea for IssueM started a couple years ago, and even started as a plugin, then morphed into a theme, and now it is back to a plugin. There was a lot of reasoning for these changes, but the biggest was that we wanted to make a plugin that could be used in any theme. Since the IssueM theme didn’t suit everyone’s needs, it was much easier to turn the functionality into shortcodes and widgets. Plus, since WordPress 3.1, we have all the capabilities we need to make a plugin extremely useful and successful in this arena.

Anyway, since this is a premium plugin we need a way to notify people of plugin updates. Frankly, I have never needed to do this, so I needed to figure it out. Luckily, I have a copy of Professional WordPress Plugin Development and in Chapter 9 there is very simple example of exactly what I wanted to do. Unluckily, the example doesn’t work… well, not entirely. It was always reporting an update, even if it was on the latest version. But I had enough information to trace down what was happening and figure out what I needed to change. By the way, the example code for the book is available from the publisher’s website.

So, without further adieu, this is a modified version of what I did:

This is the code I added to my plugin:

Then I setup a WordPress install for my API and created a custom template for the API page

This isn’t exactly what I did, but it’s much more basic. Here are some things you can think about. First, the IssueM plugin uses an API key, so I send the API Key to api to verify the user has the right to update the plugin (say they don’t pay next year or something). The download_link setting is dynamic, for IssueM, it’s something like http://api.url/download/location?api=API_KEY. Then I have a separate script at the download location that will also verify the API Key and will send the latest IssueM plugin (which is located in a hidden directory). I also didn’t hard-code the downloaded argument, I actually track the downloads by using the dynamic download script. So my $response->downloaded actually equals get_option( ‘my_plugin_downloads’ ).

The download script I setup looks something like this:

You can completely customize and expand this code to do whatever you want. By adding extra arguments being sent to your API, you could have several plugins in this same repository. You can send API key information, host information, and anything else you’d need/want.

Comments

  1. Nice write up!

    Unfortunately, you’re right, there’s a typo (or plain error) in the code given in the Professional WordPress Plugin Development and the solution you worked out was essentially the same as the one I had arrived at. I spent a fair bit of time before I realised the error in the code!

    I’m curious that your simplified download script uses the wp_options table for storing download stats, as I would have expected this script to be outside your WP install.

    Anyway, thanks for writing this up!

  2. Is this the only change:

    if( version_compare( $response->new_version, $transient->checked[$plugin_path], ‘>’ ) )
    $transient->response[$plugin_path] = $response;

    While that fixes most of it, the only thing it leaves is that circled number on the plugins page, that indicates an upgrade (though it does not say which one it is for).

    -Chris

Speak Your Mind

*