Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: [wiki] Testing 1, 2, 3...Plugin Archive in TextBook?
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)
Offline
Re: [wiki] Testing 1, 2, 3...Plugin Archive in TextBook?
Destry wrote:
… 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.
Offline
Re: [wiki] Testing 1, 2, 3...Plugin Archive in TextBook?
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:
- a safehouse of plugin files when their not attainable anywhere else,
- an easy to scan (and categorized) listing of plugins for quick search and retrieval,
- and a community editable documenation page to expand on the documentation that too many plugin authors are often so bad at writing themselves (no offense people, writing isn’t easy, I know, it takes time/effort and editing). Not to mention making the documentation available for quick translation into other languages.
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.
Offline
Re: [wiki] Testing 1, 2, 3...Plugin Archive in TextBook?
Destry wrote:
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)
Offline
Re: [wiki] Testing 1, 2, 3...Plugin Archive in TextBook?
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.
Offline
Re: [wiki] Testing 1, 2, 3...Plugin Archive in TextBook?
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.
Offline
Re: [wiki] Testing 1, 2, 3...Plugin Archive in TextBook?
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.
Stuart
In a Time of Universal Deceit
Telling the Truth is Revolutionary.
Offline
Re: [wiki] Testing 1, 2, 3...Plugin Archive in TextBook?
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:
- Headers are easily handled by adding equal signs before and after the header text, the same number for each header level it represents:<code> = Header 1 = </code>, etc. (Can’t seem to show more examples here because of Textile, but I think you get the idea.)
- You write paragraphs like normal without any tag syntax at all. The wiki knows it’s a pargraph and formats it accordingly.
- Ordered and unordered lists are handled exactly the same as Textile; an octothorpe (#) for numbers, an asterisk (*) for bullets.
- Links are handled in two ways depending on if it’s an external link or an internal wiki link:
- External links use the following … <code>[http://127.0.0.1 localhost]</code> which produces a link as localhost. You can also leave the label part out and just go with the URL alone … <code>[http://127.0.0.1]</code> … giving http://127.0.0.1. When formatted this way, external links automatically have a little arrow added to them to indicate it’s an external link.
- Internal links use … <code>[[Page Title Here]]</code>. The difference being the double straight brackets and no URL is needed, just the title of the desired wiki page (without underscores between words). You can change the way an internal link label appear by adding a pipe and then the alternative label syntax … <code>[[Page Title Here|Tailored Link Label]]</code>. More internal link techniques, like anchors, are noted here.
- For bold, italics, and underline there are quick-click buttons in the editing view to make it easy. You simply highlight what you want to apply the style to and click the button accordingly.
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.
Offline
Re: [wiki] Testing 1, 2, 3...Plugin Archive in TextBook?
Okey dokey. Looks like I shall have to get a login then. ;)
Stuart
In a Time of Universal Deceit
Telling the Truth is Revolutionary.
Offline
Re: [wiki] Testing 1, 2, 3...Plugin Archive in TextBook?
thebombsite wrote: 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?
Sorry, tbs, I totally forgot to answer your question and you probably took my response as an implication to something else. ;)
Yes, you can just email it to me, but let me just say that your docs are one of those that are rather good. If it goes into TextBook, it would most likely just be for translation purposes (which is nice) and whatever little upgrades were needed over time. Your contribution is much appreciated.
We’ll get you that account anyway, who knows. ;)
To be clear, here’s the specific link.
Last edited by Destry (2006-08-09 11:07:46)
Offline
Re: [wiki] Testing 1, 2, 3...Plugin Archive in TextBook?
I’ve come across a couple of PHP scripts that serve as download interfaces and counters. Just for curiosity I’ve installed one called PHP Easy Downloader. You can see it working in the wiki now right here (temporary).
I like the potential of this. It works independent of a database; it’s simply pulling files from the folder they are already uploaded to via the wiki and outputting them in a table when a user visits the above address. At the moment there’s a couple kinks that need worked out. For example I have it set to show .txt files too, but that doesn’t seem to be working. Also, for it to be really worthwhile, it would need to be modified to show all the fields I already have setup in the plugin archive.
The benefits though, besides the counting feature, are an easier means updating the archives and each plugins details:
- Use the wiki upload feature to initially load a file.
- Use the PHP interface (indicated above) to update such things as additional link locations, description, and so forth. No more complex wiki tables to wrangle.
Making the output more attractive is an easy matter, but I would need help with customizing the script a bit to allow for additional fields and fix the .txt file issue.
If a plugin was built to handle file output (as a full options table like in the wiki) then the archive would be equally managable at .org too.
Offline
Re: [wiki] Testing 1, 2, 3...Plugin Archive in TextBook?
It’s been brought to my attention that textpattern.org is undergoing rejuvenation, and that a better plugin archiving process will be implemented there. TeamTextpattern would like to focus plugin archiving activities in that direction. Hence, further work on the wiki plugin archive is frozen and those pages will be deprecated once textpattern.org is re-re-released.
(Sorry hakjoon, I forgot to pass that tidbit along.)
Offline