txp_plugininstaller: a convention for the TXP plugins update

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.

jsoo · 2009-09-28 13:46:07

Bloke wrote:

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.

Thanks for the very thoughtful reply. Actually that fits pretty well with ‘obvious’, if only I knew enough about feeds generally and Txp feeds particularly to have seen it. Exactly the sort of info I was looking for.

I’m certainly going to wait to see if anyone picks up the centralized-system ball and runs with it, before trying anything myself.

Bloke · 2009-09-28 14:05:10

jsoo wrote:

if only I knew enough about feeds generally and Txp feeds particularly

Hehehe, it was a dark art to me at first! For the record, here’s an example of the sort of thing I knocked up for the admin themes. I put this in the Page Template for a section called update:

<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title>Updates</title>
 <link href="http://textgarden.org/update" rel="self"/>
 <link href="http://textgarden.org/"/>
 <updated><txp:php>echo date("Y-m-d").'T'.date("H:i:s").'Z';</txp:php></updated>
 <author>
   <name>Admin Theme Updates</name>
   <email>someone@textgarden.org</email>
 </author>
 <id>textgarden-admin-theme-update</id>
 <txp:article_custom category='<txp:adi_gps name="category" />'>
  <entry>
   <name><txp:article_url_title /></name>
   <title><txp:title /></title>
   <link><txp:permlink /></link>
   <id><txp:article_id /></id>
   <updated><txp:modified format="%Y-%m-%dT%H:%M:%SZ"/></updated>
   <summary><txp:custom_field name="version" /></summary>
  </entry>
 </txp:article_custom>
</feed>

And that was it. Visiting textgarden.org/update sent the feed to the browser that listed all the themes on Textgarden and their version numbers. I cheated a bit because each theme had its own article so I used article_custom to grab them and format them in the container. But an smd_query or a simple bit of PHP would do the job equally well to get stuff from another DB table. It changed somewhat for the final version that Stuart put together, but essentially the feed above is what smd_admin_themes reads to determine which themes are newer than the ones you have installed.

EDIT: I used adi_gps here so the feed could work for different URL-supplied categories, but we didn’t use it in the final version.

Last edited by Bloke (2009-09-28 14:25:50)

JanDW · 2009-09-28 18:19:28

Bloke wrote:

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.

Can I put this convention into textbook? Under Plugin Development Guidelines maybe?

Bloke · 2009-09-28 18:40:11

JanDW wrote:

Can I put this convention into textbook? Under Plugin Development Guidelines maybe?

Sure thing, good idea. Great place for it instead of being buried in the forum. And if while doing it you come up with any cool ideas for perhaps the ordering of the sections or anything that’d make it easier for people to use the docs, chuck them in there too!

Last edited by Bloke (2009-09-28 18:41:04)

JanDW · 2009-09-29 00:11:16

Ok, just did a quick and dirty edit on textbook . (No cool ideas, maybe one day…) Hopefully people can improve on it

Back on topic… Is there no other CMS that has an interesting solution to this that might work for txp?

I agree that it’s up to the user to install an update or not.

Last edited by JanDW (2009-09-29 00:12:58)

Textpattern CMS

Textpattern CMS support forum

#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

#16 2009-09-28 13:46:07

Re: txp_plugininstaller: a convention for the TXP plugins update

#17 2009-09-28 14:05:10

Re: txp_plugininstaller: a convention for the TXP plugins update

#18 2009-09-28 18:19:28

Re: txp_plugininstaller: a convention for the TXP plugins update

#19 2009-09-28 18:40:11

Re: txp_plugininstaller: a convention for the TXP plugins update

#20 2009-09-29 00:11:16

Re: txp_plugininstaller: a convention for the TXP plugins update

Board footer