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).

colak · 2009-09-27 09:38:29

FireFusion wrote:

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.

I agree. Some of us work with hacks in the plugins which would be superseded with an automatic update.

Mac osX.y notifies us whenever there is an update but gives us a choice what we want to have updated.

What worries me with centralising the plugins on textpattern.org is the load the server may have to take. But, like Bloke, I have no access to the server so I don’t know.

jsoo · 2009-09-27 12:29:18

Half-a(s|r)sed idea, but one I might actually try to implement:

Background: Having finally got wise to rah_plugin_download, and with my own soo_plugin_display, I now have most of my plugins set up so that when I install the new version on my personal site, all the relevant pages are automatically up to date: download file, version number, code preview, and documentation. So, along of this thread, I’m thinking of how to auto-generate an XML feed entry at the same time. Knowing next to nothing about feeds, I’m naturally thinking of using a standard Txp setup, based on articles. If I’m overlooking something obvious perhaps someone will chime in?

I’m thinking of a plugin that will auto-publish an article when a compatible plugin is installed (or perhaps enabled instead). The compatible plugin would have a plugin_lifecycle callback that would hand things over to the auto-publish plugin (APP). APP adds a new article to the section that will be used for the feed, first checking that this is indeed a new version. Article title would be in the format “plugin_name version version_number” (running “version” through gTxt()), allowing for the version check. Or could use a custom field, but I don’t think it’s needed. Article body would contain the version history extracted from the help text (by soo_plugin_display), or alternately the entire help text.

Still pondering how to generate the link to the info/download page. Possibilities:

include it at the top of version history or help text so it’s there at the top of the feed item
just use author_uri for the plugin
include it in plugin help with an appropriate id so soo_plugin_display can extract it separately

Could have an option to publish the new article as Draft, in case you are still testing the plugin. Or publish it an hour in the future.

Bloke · 2009-09-28 12:58:29

jsoo wrote

If I’m overlooking something obvious perhaps someone will chime in?

That’s a nice idea for people developing their own plugins. But since in a decentralized system — as Gocom pointed out — something like the Admin->Plugins tab wouldn’t necessarily know to look at that feed, the same applies to textpattern.org; how does it know where to get the info? A ‘pull’ technology such as RSS needs someone or something to keep the location of all 3rd party site locations up to date. A ‘push to textpattern.org’ is what’s needed to tell it to check for new content; even if that push is a simple “look at me” like this:

textpattern.org/updates?from=http://ipsedixit.net/my_plugins

which generates a feed that textpattern.org knows what to do with. Of course that implies the kind of security whatnots I mentioned earlier if it’s updating articles in the database. Wouldn’t want any old doohicky creating a feed and causing mayhem.

Though it doesn’t come under the banner of ‘obvious’ you might save some hassle by creating the feed directly instead of auto-adding articles to your own TXP. A very simple plugin could do it based on some attributes that govern which plugins to include in the feed. For example, intercept a 404 call to a dummy section called my_plugins — there’s a cool hook for this in 4.2.0 that smd_lately employs — and use some cheeky PHP or abc_some_plugin to grab the (perhaps filtered) contents of the txp_plugin table. I thought rah_plugin did that kind of thing already but I’ve not read the docs yet; perhaps it doesn’t do feeds.

Once you have the plugin info, generate a feed off the back of the 404: change the status, set the header and squirt out the feed. The format of the feed itself is just a standard XML jobbie that can be built up by iterating over the returned rows. But the URLs that textpattern.org needs — such as download link, plugin page, forum link, etc etc — are more tricky to come by automatically, as you say. Perhaps that’s where your article approach shines because there is a physical page for it.

Alternatively, marry the two: when there’s a call to (the usually 404) my_plugins/abc_plugin_name, generate a fake article there containing all the relevant details/help/links and serve it. Probably needs some more thought here, this is just off the top of my head, so might be complete gibberish.

Either way, sending data to textpattern.org and auto-updating it like a package server is not something I’d like to tackle… far too much to go wrong!

candyman wrote:

This is dangerous in case one author decides to close his site: the updates will become unavailable.

True, but that’s no different to now. Yeah it sucks when a truly cool plugin goes away but then an old plugin is not guaranteed to work on a new version of TXP anyway so the fact it essentially dies with the older version of TXP forces the issue of adoption or a rewrite by someone else. Not saying this is perfect or desirable, just reality.

The only way that textpattern.org could be used as a distribution server is:

if it’s easy for authors to publish their plugins there
the load / bandwidth are available and won’t be exceeded, because that’s costly

From what I can gather, plugin authors tend to do stuff on their own sites so to have to do it twice — upload the new content to a separate server — is a pain. Which is why the holy grail is the ability to develop plugins remotely and then as part of the release process simply tell textpattern.org (even semi-automatically is better than nothing) about it and that does the necessary updating/creation.

One thing I did wonder about was that instead of sodding about with uploading files to textpattern.org, whether one of the article fields could be used as a repository for the latest base64 plugin code. That could be populated via whatever mechanism (perhaps automatically if we can figure out the details) and therefore the plugin is essentially always available because it’s embedded in the article and is a click away without having to go to the author’s site. Download counts go out the window of course, which are sometimes nice to maintain and authors like them. The trouble is, which field can it go in? Custom fields are too small and excerpt/body are already used.

btw, I agree that automatic updates are a pain and should never be pursued. Site owners should stay in control of the plugins used on their sites. If any auto-update system is put in place, it should be an advisory only with the option to download the new version if you wish.

I also think that a standard plugin documentation directives should be decided too:

Manfre tried a while ago and I do try to stick to that convention though it didn’t specify style so they won’t all look the same.

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

#13 2009-09-27 09:38:29

Re: txp_plugininstaller: a convention for the TXP plugins update

#14 2009-09-27 12:29:18

Re: txp_plugininstaller: a convention for the TXP plugins update

#15 2009-09-28 12:58:29

Re: txp_plugininstaller: a convention for the TXP plugins update

Board footer