txp_plugininstaller: a convention for the TXP plugins update

candyman · 2009-09-23 13:11:11

It would be too difficul to impose a check_for_update_convention to the txp plugin developers – like the one of the three letters before the plugin name – in order to obtain a way to automatically check&upgrade all the txp-related plugins?

I’m thinking to a sort of Rob Sable’s rss_plugininstaller working for all the plugins created for Textpattern. The check for the latest versions could be done using the Texpattern Resources site.

Just a thought.

variaas · 2009-09-23 13:52:01

I started working on this a long time ago but just never had the time to get it completed. I had created two plugins:

asv_plugin_ditributor – this is the plugin a plugin author could install to create an rss feed of plugins. The rss file could be hand created so it’s not required

asv_plugin_installer – this is an adaptation of Rob Sable’s plugin to accept other rss feeds.

Last edited by variaas (2009-09-23 13:52:31)

candyman · 2009-09-23 14:05:35

Thanks Amit!

It would be nice it could become a standard.

JanDW · 2009-09-23 15:14:35

I’ve been wanting this too. It would be a great feature if there was a standard way of doing this…

jstubbs · 2009-09-23 16:38:24

I’d love this!

Bloke · 2009-09-26 18:49:03

The good news is that a check for updates feature is fairly trivial to implement as demonstrated in smd_admin_themes. It’s not bulletproof, but all it requires is a custom XML feed that contains pertinent information about either the requested or all plugins.

The obvious place to do this is textpattern.org because there is a custom field that contains the version number, plus a status field and a few other goodies (like a direct link to the new plugin / the author’s site). All this info could be rolled into a feed accessed either by:

textpattern.org/updates?c=plugins

or

textpattern.org/updates?c=plugins&plugin=soo_image&smd_if&mem_form&...

Then the core (if on the Plugins tab, since no plugins can run there) or a plugin on the Extensions tab could simply request the feed on demand — either per plugin, for a set of plugins, for all installed plugins, or for all plugins in the repo. What is done with the return feed is then a matter of boring details.

Things to consider with this approach:

Someone with TXP access to textpattern.org would have to set up the feed and the dummy section updates — I don’t know who has Publisher access here; it ain’t me
The feed needs defining in terms of what it should contain, the names of the XML tags, and how it should be triggered
The mechanism for server balancing should be specified. In smd_admin_themes I simply queried the textgarden repo and locally cached the results (as a hidden pref) for 24 hours. It’s manually overridable if you know the right URL param to add; I could have made a Check Now button but chose not to. Thus the server only gets hit once every 24 hours (maximum) from each remote client
If this becomes a core feature, how should it be presented? Again, in smd_admin_themes, if a new version is available I simply bolded and hyperlinked the version number to the theme’s page on textgarden whereby someone could choose to download it. Any number of things could be done here: link to the textpattern.org page; direct link to the plugin’s .txt file; auto-install by fetching the txt file and pasting it in the Install box (perhaps jQuery could do this and ‘submit’?); and so on. This also means that if it is a core feature it needs to be done right because the core release cycle is long compared to a plugin. fwiw I’d favour a plugin approach, even though it’s not as ‘immediate’ and means duplicating some stuff from the Plugins tab — it would be better if a plugin could hook directly into the Plugins tab via pluggable_ui, but that’s out of scope given the None Shall Pass restriction
Anyone who chooses not to list their plugins on textpattern.org or doesn’t keep the version numbers up to date won’t be in the running to deliver updates automatically — this could be a lifestyle choice by the plugin author, which may be considered a feature rather than a hindrance ;-)

That’s the way I’d approach it anyway. Whether it’s the best way or there’s something better I don’t know. This method has the potential to be a non-core feature which is great because it opens up the floor to some clever plugin authors to make a slick plugin updater module for TXP based on a well-defined XML feed spec. The only difficult decision is whether the plugin itself should be able to be updated by itself on its own tab and, if so, will it become self aware and start shooting people until John Connor saves the day.

Last edited by Bloke (2009-09-26 18:52:02)

Gocom · 2009-09-26 20:45:02

Stef’s idea is the best in my opinion. It’s the standard method how all package controls work:

Textpattern.org servers list of plugin feed (plugin name, newest version etc).
Plugin author own site/server serves the files, downloads and information.
Plugin author can choose if s/he just publishes link to the plugin site, external hosts files or what.
Textpattern.org can auto-check updates from author sites (=distro servers). So the author doesn’t have to update anything to TXP.org.

Bloke wrote:

Anyone who chooses not to list their plugins on textpattern.org or doesn’t keep the version numbers up to date won’t be in the running to deliver updates automatically — this could be a lifestyle choice by the plugin author, which may be considered a feature rather than a hindrance ;-)

Heh, there is no way I’m going to update anything to 3rd party site (textpattern.org). So the system has to have some sort auto-fetch system that checks the new versions and plugins from author’s site. For example this could be done with small xml or txt files that is server by the author site (that wants to be part of the package distro). This is also what stannard package control does.

But I’m totally againts:

That the plugins files are required to be uploaded to Textpattern.org.
IMO, the files need to be externaly served by possibly author server, and the plugin author does NOT have to update ANYTHING to Textpattern.org, just to his own site/system.

Last edited by Gocom (2009-09-26 21:06:57)

jsoo · 2009-09-26 21:15:13

Gocom wrote:

Heh, there is no way I’m going to update anything to 3rd party site (textpattern.org). So the system has to have some sort auto-fetch system that checks the new versions and plugins from author’s site.

Agreed: for the plugin author it needs to be as simple as installing the latest version of the plugin on your own plugin documentation/distribution site. Any duplication of effort required will result in missed updates on the automatic “check for updates” system.

Bloke · 2009-09-26 21:15:57

Gocom wrote:

Textpattern.org can auto-check updates from author sites (=distro servers). So the author doesn’t have to update anything to TXP.org.

That would be lovely :-) Questions:

How would textpattern.org (a TXP site) go about creating or updating articles automatically from an author’s site when they wrote a new plugin or changed an existing one?
How would the system authenticate so it didn’t receive crap/spam from a non-author? Or from someone pretending to be a legitimate author?

there is no way I’m going to update anything to 3rd party site (textpattern.org).

It looks like your textpattern.org entries are all updated and reflect the latest versions of your plugins… so you already are updating info to a 3rd party site, right? But I admit it is a pain to have to do it twice.

But I’m totally againts That the plugins files are required to be uploaded to Textpattern.org.

Although a central repo would help prevent (to some degree) dead plugin links when authors walk away, it is an extra hassle I could do without so I’m happy to keep hosting plugins on my own site. Especially since it’s so easy with the help of rah_plugin_download ;-) (I’ve not tried rah_plugin yet, sorry)

Last edited by Bloke (2009-09-26 21:17:15)

Gocom · 2009-09-26 21:36:33

Bloke wrote:

It looks like your textpattern.org entries are all updated and reflect the latest versions of your plugins… so you already are updating info to a 3rd party site, right? But I admit it is a pain to have to do it twice.

Yes. It’s pain in the ass. In the current system, I can’t say I’m really updating the info, I’m more just posting the all articles in a one go. As you can see the info is literaly old, non-existing and TXP.org possibly misses some rah_plugins ;) That wouldn’t work for auto-update system.

Automatic system would be 100% kickass. Something I really like.

I’ve not tried rah_plugin yet, sorry

It’s safer to not use it, betas do horrib things ;)

Last edited by Gocom (2009-09-26 21:38:41)

FireFusion · 2009-09-27 09:14:10

Personally i’d just settle for a automatic notification of a new version and a link to the page where I could download the update, be it textpattern.org or third party. That way I could read any upgrade notices, changelogs of requirements before i decide to update.

It could be displayed in the plugin page next to the version number. Then we’d just need the author to create a version RSS feed, with a link to github or where ever their new versions are.

candyman · 2009-09-27 09:21:24

Gocom wrote:

I’m totally againts:

That the plugins files are required to be uploaded to Textpattern.org.

IMO, the files need to be externaly served by possibly author server, and the plugin author does NOT have to update ANYTHING to Textpattern.org, just to his own site/system.

This is dangerous in case one author decides to close his site: the updates will become unavailable.
For sure there’s a reason for your choice: can you explain why the use of Texpattern.org must be avoided?

Bloke wrote:

How would textpattern.org (a TXP site) go about creating or updating articles automatically from an author’s site when they wrote a new plugin or changed an existing one?

How would the system authenticate so it didn’t receive crap/spam from a non-author? Or from someone pretending to be a legitimate author?

The use of Texpattern.org as an official plugin source wouldn’t solve these problems?

I also think that a standard plugin documentation directives should be decided too: in that way all the docs will have the same look&feel (but, I know, this is a very little problem, so far).

Textpattern CMS

Textpattern CMS support forum

#1 2009-09-23 13:11:11

txp_plugininstaller: a convention for the TXP plugins update

#2 2009-09-23 13:52:01

Re: txp_plugininstaller: a convention for the TXP plugins update

#3 2009-09-23 14:05:35

Re: txp_plugininstaller: a convention for the TXP plugins update

#4 2009-09-23 15:14:35

Re: txp_plugininstaller: a convention for the TXP plugins update

#5 2009-09-23 16:38:24

Re: txp_plugininstaller: a convention for the TXP plugins update

#6 2009-09-26 18:49:03

Re: txp_plugininstaller: a convention for the TXP plugins update

#7 2009-09-26 20:45:02

Re: txp_plugininstaller: a convention for the TXP plugins update

#8 2009-09-26 21:15:13

Re: txp_plugininstaller: a convention for the TXP plugins update

#9 2009-09-26 21:15:57

Re: txp_plugininstaller: a convention for the TXP plugins update

#10 2009-09-26 21:36:33

Re: txp_plugininstaller: a convention for the TXP plugins update

#11 2009-09-27 09:14:10

Re: txp_plugininstaller: a convention for the TXP plugins update

#12 2009-09-27 09:21:24

Re: txp_plugininstaller: a convention for the TXP plugins update

Board footer