soo_plug_up: Automatic version check and update for compatible plugins

jsoo · 2011-01-04 04:00:10

Vaporware alert: not released yet. But soon, really. I wanted a support topic so I could include the link in the plugin help text, and more importantly, would like some feedback from plugin authors and potential users.

Over the years there have been various discussions on how to create a centralized plugin repo that would ease the pain of keeping plugins up to date on a Txp site. Some plugin authors have made such things for their own plugins. Other attempts appear occasionally.

I recently found myself unable to keep track of even my own plugins on installed sites, so I decided to make my own attempt at a solution. It has to be easy for both end users and plugin authors. I am as lazy as anyone and don’t want to be bothered with extra tasks each time I release a plugin update.

What I’ve come up with for users is an admin panel, installed under Extensions, where you can check all your plugins at once. Each time you navigate to this Plugin Update panel, each registered plugin pings home to see if there is a new version available. If there is, one click takes care of the download and sends you to the plugin verification step.

The main catch is that this will only work for compatible plugins. But I believe I’ve made it very easy for plugin authors to meet these requirements. The plugin download site must respond correctly to two pings, one for the version check and one for the download URI. The ping URIs start with each plugin’s author_uri field, and add query paramaters for rah_external_output, so a plugin author must install that plugin on the download site (or otherwise spoof its behavior), and configure it to respond correctly to the two pings. Finally, you must provide a stable download URI for each plugin, one that does not change from version to version. rah_plugin_download is an excellent way to manage this (and is excellent for many other reasons), but is not required.

To be clear, these requirements are for the plugin download sites only. End users need only install the soo_plug_up plugin and then register plugins through its Plugin Update tab. (PHP 5 with the curl extension is required for soo_plug_up.)

A potential catch is plugins with dependencies, where upgrading is best performed in a particular sequence. I did this myself with the Multidoc 2 release. I don’t have an answer for this, but I don’t see it as much of an issue. If necessary, you could disable the ping for that plugin while you broadcast the upgrade requirements on the forum etc.

I am, as I said, very close to releasing this, but am still very willing to consider suggestions from both sides: end user and plugin author. If you’re a plugin author and want to try the alpha version, let me know. I’d love to have more than just my plugins available when I release it.

jsoo · 2011-01-05 02:37:02

Teaser screenshot:

This is the soo_plug_up main admin panel. When a version number appears red, an update is available. Clicking the number immediately downloads the new version and takes you directly to the installation verification panel.

Clicking an unregistered plugin will add it to the list of updatable plugins, if it is compatible with soo_plug_up.

gomedia · 2011-01-05 04:47:31

Hi Jeff,

Interesting stuff.

I use a private, customised version of rss_pluginstaller which allows me to install/upgrade plugins not only from my “pantry” but also from my online adi_plugin collection. They’re served up differently – my plugins are stored as source code & served up using zem_tpl.php, other peoples are stored as encoded .txt files.

One other big difference is that I don’t have a “stable download URI for each plugin” – the url changes between versions. It’s too hard to keep track otherwise. It means I can store different versions of the same plugin as well.

Bloke · 2011-01-05 08:57:40

Nice one Jeff. The new .org site has a feed available for that exact purpose. It’s already implemented and my tentative new TXP 5 Admin->Plugins pane has the ability to show updates directly. If you want to use the .org feed, contact me (heck, if you’d like to lend a hand with coding for .org, shout: it’s bigger than I thought!)

EDIT: the feed only contains plugin name, .org URL and version number right now since that’s all that .org requires. But if it’s useful for other plugins such as this to have more info (e.g. direct access download link) it can easily be built into the feed.

Last edited by Bloke (2011-01-05 09:31:51)

jsoo · 2011-01-05 12:04:28

Adi:

Actually I could drop the stable URL requirement, and use an extra ping step when upgrading a plugin. Slows down the upgrade step a little, but reasonable.

If you have to go out and collect versions for your “pantry”, you’re doing more work than I want to do as a site maintainer :) I want something automatic.

Stef:

If .org is going to work with no significant pain for plugin authors, and one-click upgrade for end users, then obviously that’s the way to go and my plugin is not needed. But Txp 5 is still a ways off, no? Can you share more info as to how the feed will work, both for plugin authors and for end users? Edit: [Also, what kind of coding help is needed? Feeds not a strong point for me:)]

Last edited by jsoo (2011-01-05 12:09:56)

Bloke · 2011-01-05 12:39:24

jsoo wrote:

If .org is going to work with no significant pain for plugin authors

That’s the plan :-) Delivery subject to availability, YMMV, some settling may occur in transit, etc.

But Txp 5 is still a ways off, no?

Correct. But the first drop of .org isn’t that far away (honest!) — I’m going to phase the releases. All I wondered was that instead of building the framework around a custom system in your plugin you might be able to save yourself a bit of hassle and utilise the feed on .org instead, then we can all use your plugin as a stop-gap solution until TXP 5 rolls into port.

Can you share more info as to how the feed will work

Sure. There are two aspects:

1) For end users, the feed URL simply takes a list of currently installed plugin names (essentially textpattern.org/update?smd_query&soo_multidoc&abc_wizzo&... via GET or POST (preferred)) and it returns an XML document with those names, current version, and a link to the .org plugin page — NOT the direct download, although it’s a piece of cake to add to the feed if necessary. From there a plugin / the core can do what it likes with the data. From a technology perspective the TXP 5 solution to grab the feed uses standard fopen with a URL param or, if allow_fopen_url is not available, curl. Or the other way round I suppose.

2) For plugin authors there will, in Phase 2 now, be the ability to get .org to ‘subscribe’ to your own web site. I’ll not divulge the tech details here (mainly because they’re only in my head right now) but essentially you can set up a similar feed on your own site to notify .org of changes. By simply visiting your own, private, URL on .org that will be issued from your .org profile page when you set up backfeeds, you’ll see a list of all things that are different between your own site’s plugin / version info and the stuff stored on .org. Each difference is checked automatically but you can always uncheck any you don’t want to sync for some reason (your stated example of dependency plugins springs to mind) and when you hit the Go button, all the selected details will be updated automatically on .org to reflect your own site.

Your custom feed can include changelog details or you can supply that at Go time on a per-plugin basis if you prefer. Changelogs are stored on .org now as a permanent record for each plugin so there’s no need to embed the changelog details in the help file unless you really want to. The idea is that once you’ve published plugins/updates on your own site you visit your private .org URL, hit Go and you’re done (not going to rely on cron to pull the updates in, although I suppose we could if I had such access).

There are safeguards in place such that you can only modify your own plugins — or those for which you are the designated maintainer — and some extra checks to make sure bots and unscrupulous entities don’t make changes to your plugins — and of course you need a login on .org which pretty much every plugin author already has.

This step is largely vapourware right now but it’s all very doable.

[Also, what kind of coding help is needed? Feeds not a strong point for me:)]

the remaining form processing stuff using mem_form and/or smd_query
allowing updates to the compatibility matrix
custom search
Phase 2 :-)

The rest is just CSS fluff and HTML drudgery to shift stuff about and make it all look pretty / work with the minimal amount of clickage. Jonathan’s got his face embedded in that right now. I’m trying to fit the login/edit bar into the design in a logical place and make sure it functions reliably.

Last edited by Bloke (2011-01-05 12:39:55)

ruud · 2011-01-05 12:48:53

Two things to consider:

Some plugin versions only work with specific TXP versions.
Some plugins change functionality in an way that is not backwards compatible.

In both cases, if a user were to upgrade simply because an update is available, it could cause problems.

Bloke · 2011-01-05 13:05:17

ruud

Yep, that’s what the compatibility matrix aims to address: it matches plugin version to TXP version and offers a ‘grade’ of compatibility likelihood. The custom search facility allows you to choose:

“definite” : the author has stated that plugin A.B.C works with TXP X.Y.Z
“likely” : based on user feedback, plugin A.B.C is likely to work with TXP X.Y.Z, or will work if you modify lines M and N
“maybe” : you’re on your own

Whether that compatibility info is taken into account in the information sent back from the feed to the admin side / Jeff’s plugin is down to implementation details. There’s nothing to stop the calling system from specifying the current TXP version installed and the degree of risk a user wishes to take on being notified. If you only want to know when definite plugin updates for your current version are available, that should be the, probably default, option.

Either way, it is not (currently) planned for the core to offer the one-click install facility. The link next to each installed plugin that indicates an upgrade is available takes you to the .org plugin page and, from there, you can read about it and decide if you want to upgrade based on all the info collected there before clicking the download link and installing as usual. Jeff’s plugin can offer the one-click option for people who really really want one click installation and implicitly trust their plugin authors :-) [ EDIT: and that’s another reason for Jeff to try and use the official feed in his plugin because he gets all this extra info for free! ]

Last edited by Bloke (2011-01-05 13:11:12)

jsoo · 2011-01-05 13:48:14

Ruud:

Thanks, and clearly I will need to offer other options than just “blindly click this link and possibly bring your site to its knees”.

[Edit: I could follow Google’s example and show the link as a big “I’m Feeling Lucky” button.]

Stef:

Sounds fantastic, count me in. Give me a bit of help plugging into the .org feed, and let me know how I can contribute on the .org end.

Last edited by jsoo (2011-01-05 14:35:33)

jsoo · 2011-01-05 21:26:26

OK, so this plugin is still in the works, but will remain vaporware a bit longer while the details of the textpattern.org feed are being worked out.

Gocom · 2011-01-08 22:13:22

Jeff, sounds nice. The plugin could have lot of potential if done right.

Would be cool (or would it?) if it had optional donation support, for example displayed tiny little donation button when installing/updating a plugin, (urghh that sound so creeeedddyyyyyy and nagwareish, and would possibly put some ppl off).

Will the plugin have caching, and how will it automatically check for updates? Will it ping every site in one go, or will every site have own cache. But now when you are looking into .org feed, it will probably use that instead, so it won’t do mass pinging at all. Expect that .org isn’t live yet.

I had similiar of plans with rah_plugin_installer (with version 0.2, originally), but it never made it, expect for the left over code the plugin has. Can’t wait to see what your plugin can offer :-)

Last edited by Gocom (2011-01-08 22:15:42)

jsoo · 2011-01-08 22:37:15

Thanks Jukka. With my original concept it did indeed ping every site every time you loaded the panel. I probably would have added a cache, to only check once per day, not that I would expect users to check the panel that often. I’ll probably add a cache for the new version, to avoid hitting the feed with too much traffic (we can dream, can’t we?).

I thought of donation support also. Since I’m now using the .org feed (it does exist even though not public yet), the Plugin Update panel includes a link to each plugin’s .org page. Stef has already included an option for donation links there. Additionally, I’m thinking of some kind of optional messaging system, for plugin authors who want to include extra information in the feed. This might include special installation instructions, or a donation request, and this might pop up as an alert if you choose the direct “one-click-upgrade” option.

I lifted some code from rah_plugin_installer :)

Textpattern CMS

Textpattern CMS support forum

#1 2011-01-04 04:00:10

soo_plug_up: Automatic version check and update for compatible plugins

#2 2011-01-05 02:37:02

Re: soo_plug_up: Automatic version check and update for compatible plugins

#3 2011-01-05 04:47:31

Re: soo_plug_up: Automatic version check and update for compatible plugins

#4 2011-01-05 08:57:40

Re: soo_plug_up: Automatic version check and update for compatible plugins

#5 2011-01-05 12:04:28

Re: soo_plug_up: Automatic version check and update for compatible plugins

#6 2011-01-05 12:39:24

Re: soo_plug_up: Automatic version check and update for compatible plugins

#7 2011-01-05 12:48:53

Re: soo_plug_up: Automatic version check and update for compatible plugins

#8 2011-01-05 13:05:17

Re: soo_plug_up: Automatic version check and update for compatible plugins

#9 2011-01-05 13:48:14

Re: soo_plug_up: Automatic version check and update for compatible plugins

#10 2011-01-05 21:26:26

Re: soo_plug_up: Automatic version check and update for compatible plugins

#11 2011-01-08 22:13:22

Re: soo_plug_up: Automatic version check and update for compatible plugins

#12 2011-01-08 22:37:15

Re: soo_plug_up: Automatic version check and update for compatible plugins

Board footer