You are not logged in.
Still with wiki formatting it looks more neat and actually like a list. I don’t think it should be any problem for anyone, it may take a while to figure out how to imitate a certain kind of a table with wiki formatting, but adding a row is plain obvious.
I agree. I’ll just leave it as it is, and if people want to convert tables to wiki formatting as things go along, that’s certainly fine with me. Thanks for setting them up with the example.
@All: If you look at the code for the first table on the Plugins Grouped by Purpose page, you’ll see what we’re referring to. If anyone would like to convert the other tables as time goes by, feel free.
Another superbly clear example of why I bothered with this…
See article, First Post, section titled Where are your Textpattern Plugins?
<big>”</big>Ah, yes, well like most of the world, they were lost in a great war. The Format of December 2005. Many files were lost and few bytes lived to tell the story. But there is a hope. If you really want the plugin that badly, try asking around on the Textpattern Forums.<big>”</big>
“Try asking around”? Come on, we can do better than that… and now we do.
Been romancing the idea of adding column for a PayPal button (perhaps the last field in each row) that gave plugin authors a direct line of donations support for their plugins. This would require that plugin authors provide their own buttons, and furthermore encourage that they help to keep their plugins updated in the archive.
I’ll integrate the col and plugin authors can add their own buttons into their respective rows. If you need a TxB account, begin here.
Oh, and please create your buttons to read “donate” exactly so their is no confusion as to what this is about, and so we keep the column sized consistently (and yes, all lower-case would be nice).
Last edited by Destry (2006-07-15 09:44:49)
… it’s another feather in their Google rankings if nothing else.
rel="nofollow" on external links won’t add much Google juice, IMHO. So its pure community charity to add a plugin there.
Ah, good point. I forgot it had been added to MediaWiki.
Nevertheless, while it may take “pure community charity” to upkeep the plugin tables (like everything else around here) the tables do provide something to the community in return:
All of which has been much needed and commented about in recent history. Even the resources site doesn’t provide that. Seems to me not contributing would reflect an attitude of indifference to support a positive change — not simply a lack of charity.
TeamTextpattern is doing a stellar job on the technology side, but there’s still a lot to be desired on the user-end/documentation side.
All of which has been much needed and commented about in recent history. Even the resources site doesn’t provide that.
Definitely true. Though the process of adding this type of content to two spots the Wiki took me two attempts, the first one being aborted by an angry “Grrr. This is simply too cumbersome.”
The second attempt succeeded by the help of MS Expression Web Designer (Beta) for the table editing. It’ll do that without hassles, in case someone wonders…
In an ideal world textpattern.org would allow uploads, and we’re done.
Last edited by wet (2006-07-18 11:16:12)
I agree a lot, wet, but not completely.
Yes, HTML tables (growing ones) are cumbersome, no doubt. Yet it’s taking me about 2 minutes now to upload a plugin file and add a row for it in two places. Not that bad once you do it a couple of times. By the way, do you think converting the tables to wiki syntax would be easier? That seems to be a prevailing question.
As for textpattern.org, I’ve voiced many times in the past that it could and should be the main plugin depository for Textpattern; it should get a complete makeover with that objective and drop everything else it tries to do (resources that are now better supported elsewhere anyway, like TxB, TxG, FAQ, etc.). I would even go so far as to give the site a title change for completeness and clarity, like Textpattern Plugins. WordPress is way ahead of the game in this respect with their WP Plugins Database (it’s butt-ugly but it’s a big step ahead of us).
Although we could add file uploading abilities to the textpattern.org Txp install, that would only solve a small step (file safeguarding), there would still be the issue of collaborative documentation development and internationalization of that documentation…here TxB has the edge, I think.
At any rate, we know Alicson can’t tend to the needed changes due to having a life outside of textpattern.org (understandable) and apparently nobody else wants to pick it up. I already tinker with TextBook so I’m not taking on the Resources site too. Since I could do something about it in TxB, I did, and in one afternoon I produced something simple that already serves better than what exists. I’ll continue to fill out the plugin archives because once the tables are full, upkeeping the tables should not be as difficult as it is creating the rows initially. Maybe more “charity” will kick-in when the value is realized. If textpattern.org gets its act together, I’ll certainly support it. In the meantime, TxB will continue to collect plugin files for safekeeping and easy access.
There’s been an Alicson sighting, and with respect to plugin file archiving no less.
I think it’s fair to say that there’s nothing like a little competition to make the lion’s eyes open (and my unspoken nav bar hypothesis appears to be true). ;) I’ve always been in favor of archiving plugins at textpattern.org, and I have said I would support it when anybody took action upon it, and it appears that might finally be happening.
Alicson, it’s really true? You’re really back? And in control of the Resources site again? Do we yet get to see the fabled redesign? ;)
I think before anyone starts uploading plugin files to textpattern.org willy-nilly you might consider some long-term planning. For example, I notice the plugin file (referenced in the link above) that was uploaded has no version indication on it. That alone will cause archiving problems, or at the very least leave a question of doubt to the user as to whether or not they actually have the right version. For example, in TxB I was giving each plugin file a name like xxx_plugin_name-n.n.ext, where “n.n” is the version of the plugin and “.ext” is either .txt or .zip as appropriate. No mistaking what is what when a version number is added to the file. Plus, this prevents overwriting plugins and losing version history. A version history is useful because it allows anyone interested in plugin development to follow the history of a plugin while they learn to write plugins themselves. It shouldn’t be overlooked; history is a resource worth capturing.
Feel free to borrow other ideas from the TextBook plugin archiving to improve the current Resources site model. For example, adding PayPal links so plugin authors get another path to potential support. Also, TextBook was doing more than just archiving the files, it was also providing a platform for anybody to expand on the documentation, whether to improve, provide real use examples, or translate. All of these are very important, because not all documentation that comes with a plugin is very good. That’s a fact.
Feel free to pull files from the TextBook archive if you want to. Some, such as certain zip packages, include all the relevant components and thus already bundled together for a single upload (making people go to three different Web sites to download different components just to use a plugin is unnecessary and silly).
With respect to the plugin documentation, I think if there’s no possibility for that expansion and translation in the Resources site, then it would be worthwhile for .net and .org to work together on this. For example, consider the TxB’s archiving tables at the moment…each row provides various links besides just those safeguarded by the wiki itself; the plugin author’s Web site as well as the relevant forum thread are linked as well. There’s no reason you couldn’t do something similar and add a “docs” link in your structure that pointed to a corresponding TxB file where doc expansion and translation could take place. Internationalization, after all, is one of Textpattern’s major selling attributes, and we should provide for that right down to the third-party plugins with a little help from the community. It’s already built into the wiki, might as well take advantage of it.
Anyway, until a clear idea of what’s going on is really ironed out, I’ll leave things as they are in TextBook, but by all means pull files as you would like.
Nice one Destry. :) With regard to the docs, as I don’t have an account and I’m really too busy to be messing around learning about wikis, what formatting is required? I mean, if I copied the docs from my articles into an email, would that be what you need to add them in?
And a minor thing that is hovering around my brain, if people can download from the wiki, my download counts will become inaccurate. Does the wiki keep a count? It’s just a minor point really.
thebombsite proffered: I’m really too busy to be messing around learning about wikis, what formatting is required?
Wiki syntax is actually quite simple for basic things, much like Textile:
That’s all most people need, and it’s certainly straightforward. Also, the wiki takes regular HTML just fine, kind of like the Textile/HTML companionship of Textpattern. It’s also generally the case that if you just get text into the wiki to begin with, somebody else will come along and add the editing/styling aspects if it’s needed. The most important thing is the text itself.
thebombsite palavered: And a minor thing that is hovering around my brain, if people can download from the wiki, my download counts will become inaccurate. Does the wiki keep a count? It’s just a minor point really.
I don’t know off hand, but I’m sure there must be some kind of php script or something that could be utilized for this. The idea for the archives, though, is not to substitute for a plugin authors’ site, it’s first and foremost role is to simply make a plugin available when the the authors site is offline, links are broken, or whatever. If you think of it in that light — if an author is not taking the care to ensure their plugin is available themselves — then their download counts are rather moot. Nevertheless, I think this is a good idea for the archives, and if there’s something that could be implemented then we should. Another column in those tables that showed download counts would be a nice addition, might help give people an idea of what plugins are popular too. We’ll look around for such a script, but we’re open to ideas as well.