[contrib] Improving textpattern.org

mrdale · 2008-08-20 17:44:12

.org should become a plugin repo, with hooks into a standard txp install.

Bloke · 2008-08-20 18:13:22

+1.

And whether or not plugins are hosted there (it’s immaterial), can I throw this out there as well:

When the TXP backend is migrated to 4.0.7, can some clever XML-RPC hook (or equivalent plugin/section) be utilised such that a remote plugin can ask the repository for details about a given plugin stored in the database there? If one of the returned fields is the current version of the plugin, I can feel the rumblings of a simple plugin (perhaps initially an enhancement to the plugin_composer, for field trials) that utilises version_compare to indicate if a newer version of a plugin is available?

It may not always be able to offer seamless upgrade unless the plugin is hosted at .org or the latest download link is current, but if the author’s website field is still correct, the least it could do is offer a link there so you can see if the latest version is available for download…

Or am I dreaming?

Last edited by Bloke (2008-08-20 20:01:42)

stopsatgreen · 2008-08-20 21:13:30

Sounds like there is a real need to get this sorted out soon. When I have time (probably next week) I’ll get in touch with Destry and find out what’s going on there, then try to put together a change proposal.

BTW, another irritant I noticed today: Archived plugins still appear in search results and lists, and it’s not until you’ve opened and read through that you realise the file is unavailable. I think files should be hosted on textpattern.org, not on the developer’s site.

ruud · 2008-08-20 21:25:36

Whoa… I think the ‘manager alert’ just went of ;)

Unless I’m mistaken, I don’t think Destry is actively involved in the development of TXP.org.

stopsatgreen · 2008-08-20 21:43:03

But I think Destry is looking at some other areas of the site, no?

And I’m not a manager. Maybe I’ve been around them too much, though…

Last edited by stopsatgreen (2008-08-20 21:43:49)

jakob · 2008-08-20 22:48:24

I think files should be hosted on textpattern.org, not on the developer’s site

I agree to an extent. There was some discussion about this already, the consensus at the end having been that it’s still up to the author to update and when they lose interest/move on/abandon or whatever, the plugins are still no longer updated. The only real benefit is that others can provide missing plugins and one can ask other members for that via the forum. Usually the problem is that a plugin is no longer kept up-to-date with current txp versions unless kind souls, such as ruud and others, step up and volunteer to take them over (zem_contact_reborn).

Dale: .org should become a plugin repo, with hooks into a standard txp install

Bloke: I can feel the rumblings of a simple plugin to indicate if a newer version of a plugin is available

The add-on repository for the vanilla forum does this. The add-ons are stored there and an update in the forum software itself checks against the most recent version number online and links back to that address. Each plug-in has a simple text file that provides the version number infos. If an add-on has been abandoned, someone else can step up to take over. I believe Mark, the vanilla dev, was later asked to develop the first iteration of mozilla’s add-on system built off this.

When I have time … then try to put together a change proposal.

Sounds like a good idea if it is constructive. Even better is if you were able to muck in actively with code and/or content that extended/pushed forward/streamlined the existing system without necessitating a revolution (technical or otherwise).
Those who have been brave enough to step up and assume responsibility for a txp-site have both my admiration and sympathy. There are lots of well-meant but often contradictory contributions being made and it must be hard to stay the course given that one can’t please everyone.

Anyhow, AFAIK Alicson is the admin of txp resources. Here too there have been discussions previously about design and content. Destry recently made a mock-up for a textbook theme that could be transferable to give the other txp sites a unified look. Peter is too working on a parallel version of the textbook (and I’ve lost track of whether these are diverging or converging).

stopsatgreen · 2008-08-20 23:12:00

Even better is if you were able to muck in actively with code and/or content that extended/pushed forward/streamlined the existing system without necessitating a revolution (technical or otherwise)

I’ll be honest, PHP is not my strong point. I’m happy to draw up some user-centred designs and pitch in with HTML & CSS, which are my strong points.

Bloke · 2008-08-20 23:59:23

stopsatgreen wrote:

bq. I think files should be hosted on textpattern.org, not on the developer’s site

I don’t mind either way. Developers have to either upload their plugins to their own site or to a central repo; makes no odds where that is. The only thing a central system ‘protects’ against is authors going away and taking their domains with them. But in the past, other forum members have posted the plugins up when asked so they’re not “lost” as such; though the onus is then on them to keep that file available.

Disk space is obviously an issue, especially if older versions are left floating around (I never delete my plugins from my own downloads dir; whether this is a good or a bad thing I don’t know).

Re: plugin updates. I can see a few ways of doing it. At each end we have a database; many client DBs and one repo DB. Someone (me if I make time and a protocol is agreed) can write a plugin that people can install which will go and check for updates to all installed/active plugins (eek, that plugin has to check itself… open the pod bay doors, Hal :-)

Problem: to check the server every time the plugins page is viewed will hammer the repo server. There are a few ways round this I can immediately see:

Do it on an ad-hoc basis with a button to click (like the current check for TXP updates), though that may still make a lot of connections if each plugin has to be queried individually
Consolidate the repo info, say, once a day on a cron job into either a DB table or an XML file so instead of asking for a whole truckload of connections, a client can make one connection, grab that file/info and then work through it locally to display the ones that have updates. This could be a biiig hunk of data
Something in between: be cunning with the API into the repo database such that one can supply a list of plugins to be returned in one hit; the requested info is bundled together and returned to the client for wading through

There are probably many others including something like jakob suggested, though that may be a little more involved than we need (I’ve not thought it through yet).

Required things on the client:

Destination address (a pref in case the repo moves)
Knowledge of the protocol used to query the remote DB, or location of consolidated file
Known format of the returned data block
A bit of grunt work to figure out what’s new and offer links to various resources if necessary (the easy bit!). The good thing about version_compare is that as long as an individual author has been consistent(ish) with versioning there’s no requirement to stick to a global convention. The comparison is only done on a per-plugin basis so a 4.3.20 -> 4.4 zem_contact_reborn is just as valid as a 0.21b -> 0.21c smd_whatever or a 0.6.12783 -> 0.7.7439 sed_something_awesome

Long-term the button to update plugins may well become built-in, but knowing if a plugin is updated or not isn’t exactly a core feature that everyone will find useful, so an optional plugin that can automate the checking process is probably as good as anything!

Trouble is I don’t even know if XML-RPC is the right tool for the job or if there’s some other way to get at the data sitting in the textpattern.org DB. Since it’s in TXP 4.0.7 as standard it’d be a shame to waste XML-RPC if it can help us in this way. I’m more than willing to have a go at this, given a bit of guidance on best practices with remote calls and how to approach it without making the server keel over in a blubbering heap under the strain.

From the look and feel side of things, if you’re willing to put some time into this, then that’s totally cool. Certainly hook up with Destry, ruud, wet, zero and others to see if textpattern.org is skinnable in the same manner as the current proposals to keep things looking sharp across the domains. I think the content nuts and bolts — the custom fields and the like — can pretty much stay as is for now. I’m not sure all of it is useful but what isn’t useful under the new presentation scheme can be hidden :-)

Last edited by Bloke (2008-08-21 00:06:10)

wet · 2008-08-21 06:22:18

Bloke wrote:

Trouble is I don’t even know if XML-RPC is the right tool for the job

I’d prefer plain HTTP ;-)

Request: http://example.com/plugin/?getversion

Reply: (MIME-Type == text/plain):

“4.08.15”

(Preliminary draft of the not-so-soon to come Textpattern Plugin Update-O-Magic)

Destry · 2008-08-21 08:19:13

ruud is correct; outside of disliking the name, which should rather be Plugins Ranch, Plugin Central, Textpattern Plugins (probably), or whatever, I have absolutely nothing to do with .org, and no time to give to it. My mockups, however, are free for Textpattern to use for it’s sites in any way. (See third paragraph.)

Jakob is correct; it is frustrating to be in official standing (standing again, by fact of this post and the two following it) with a site and have to compete needlessly with some offshoot activity. As far as I’m concerned, as far as Patrick (the current TxB manager) is concerned, and seemingly as far as wet is concerned…TextBook powered by MediaWiki, remains as the recognized documentation platform, and anything else is a contribution to it. zero now seems to be focusing on wiki content and that is a GOOD thing (with the exception it’s still happening in a different system and location). We can use that in the revamp of TextBook and everybody comes out a winner.

My mockups, strong and favorable as they are, and which depict a mode by which to integrate Txp sites, are not yet (that I can tell) approved/validated for use. Apparently we are still waiting for Matthieu to show his ideas and things have been quiet there. Since I am largely in favor of the integrated approach/presentation (as are other venerated veterans), this puts a wedge in my ability to make progress with my own area — TextBook — not to mention for others managing the forum, .org, etc. See the problem?

I’ve said it before, and I’ll say it again: I look forward to seeing what Matthieu and anyone else offers, I just hope it’s soon because obviously some of us are chomping at the bit here and it’s unfortunate progress has to hold up due to lack of communication and decision making. In fact, I’m going to add a .com mockup to my others, which will round-out my suite and serve as a good consideration against whatever else may show up. Should have it ready Monday, if not sooner.

Destry · 2008-08-21 08:55:11

My meager two coins worth of thought for .org:

1) +1 for centralized storage, like browsers at evolt browsers archive. To me this is real organization. Authors still advertise at their sites too, of course, but there should be an internal link for each plugin in the library. This is why I had started the experimental Plugins Archive in TextBook some time ago, which was merited at the time when .org was suffering. Sometimes a plugin author/link go south and it’s only by luck of someone else having a saved copy that you might be able to get it. When ruud began helping with .org, I was happy to terminate the Archive experiment.

2) +1 for stripping out all content topics that are not plugin-related…like ruud pointed out.

3) Consider removing the ability to post comments, which belong in a blog, not a library.

4) Remove any feature that is a spam risk (e.g., contact form). Use an encoded email address instead if a contact channel is needed. Consider the very fine Enkoder and call it good (don’t bother with the JavaScript turned off rubbish).

5) Some kind of donation mechanism for each plugin author, and maybe some kind of mechanism for plugin ransoms too, with status of ransom over time.

6) Automagic updating stuff people have already mentioned… +1.

7) Again, change the name!

Gocom · 2008-08-21 11:01:37

Destry wrote:

6) Automagic updating stuff people have already mentioned… +1.

And in example, we can offer easier .org plugin updating/publishing mechanism for plugin authors. In example we can build a system that gets the new plugins directly from authors website.

This is just authors own choise to activate this mechanism by activating simple plugin and submittin the own plugin repo site address to the .org.

By we can build, I really mean we. If there is need for this kind of a system, I can build it or a part of it. In example the client/plugin author side of the plugin, when someone else, like the grazy dr. bloke :), can fix and dig into the .org master system.

What it basically needs?

Time based file fetching from the author’s site
Authors site provides little file that lists all plugin names and versions that are allowed to be downloaded.
That minified plain text file won’t need much bandwidth, so it’s not issue
Those informations are compared to the .org’s archieve and if there is newer version of that plugin, then it is added to the org repo.
Those add plugins are downloaded automatically from authors site (or from author set url/SVN), but in way that stress server as little it can.

Last edited by Gocom (2008-08-21 11:06:31)

Textpattern CMS

Textpattern CMS support forum

#13 2008-08-20 17:44:12

Re: [contrib] Improving textpattern.org

#14 2008-08-20 18:13:22

Re: [contrib] Improving textpattern.org

#15 2008-08-20 21:13:30

Re: [contrib] Improving textpattern.org

#16 2008-08-20 21:25:36

Re: [contrib] Improving textpattern.org

#17 2008-08-20 21:43:03

Re: [contrib] Improving textpattern.org

#18 2008-08-20 22:48:24

Re: [contrib] Improving textpattern.org

#19 2008-08-20 23:12:00

Re: [contrib] Improving textpattern.org

#20 2008-08-20 23:59:23

Re: [contrib] Improving textpattern.org

#21 2008-08-21 06:22:18

Re: [contrib] Improving textpattern.org

#22 2008-08-21 08:19:13

Re: [contrib] Improving textpattern.org

#23 2008-08-21 08:55:11

Re: [contrib] Improving textpattern.org

#24 2008-08-21 11:01:37

Re: [contrib] Improving textpattern.org

Board footer