Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Textpattern.org v3.0 project
Its based on the current branding of TXP – so no real surprises – but it will be much better than it is now.
Offline
Re: Textpattern.org v3.0 project
Is the handling of categories going to be updated ? So we can have more than 2 categories per post ?
Offline
Re: Textpattern.org v3.0 project
It’s Textpattern! Nothing ever needs more than two categories!
Offline
#28 2010-07-12 22:12:54
- els
- Moderator
- From: The Netherlands
- Registered: 2004-06-06
- Posts: 7,458
Re: Textpattern.org v3.0 project
Removed. Don’t reply without reading properly… ;)
Last edited by els (2010-07-12 23:33:45)
Offline
Re: Textpattern.org v3.0 project
floodfish wrote:
It’s Textpattern! Nothing ever needs more than two categories!
:-)
JimJoe wrote:
Is the handling of categories going to be updated?
No plans to do so. But I have recategorised a lot of the plugins by making some better categories. A lot of stuff was mis-filed because the categories didn’t keep pace with the plugin uses. My aim is to eliminate — or at least severely dent — the number of plugins in the misc category because it serves no purpose. But I’m struggling to categorise rah_chuck_norris… damn you Jukka! :-p
Tags are being reviewed too. Currently they’re jack-all use. Seriously, they’re just useless for finding plugins. Searching for and browsing related plugins is going to form a key part of the new look txp.org and I want it to return useful results. We have some plans on how to approach this, pending a bit of free time to test it out.
Also under the knife is the way plugin authors interact with the repo. There are a lot of things going on under the hood which I’ll release teasers for as they become more concrete. We really want to ease the job of keeping the repo up to date because stuff gets forgotten due to the hurdle of keeping it maintained, and that reduces the usefulness of the repo overall. So this is high on the hit list.
Last edited by Bloke (2010-07-12 22:16:34)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Textpattern.org v3.0 project
Bloke wrote:
But I’m struggling to categorise rah_chuck_norris… damn you Jukka! :-p
I haz banhammer powerz. If you want, I can make Chuck do a kick which makes the plugin go away, and replaces it with TXPtip using smd_random_text ;-)
I suggest category just for Chuck Norris, or don’t categorise it all, making it hidden Easter Egg.
Last edited by Gocom (2010-07-12 22:55:39)
Offline
Re: Textpattern.org v3.0 project
Bloke wrote:
I’m struggling to categorise rah_chuck_norris…
aw, shucks,
IF
Chuck Norris wants his own category. Chuck Norris gets his own category. ;P
ELSE
Whimsical?
:D
Offline
Re: Textpattern.org v3.0 project
A personal perspective:
I do not read English, I décypte English. then it is extremely tiring to go through 50 or 200 pages a forum for a plugin to eventually miss important information.
Yes there are the help of plug’in, but for access they must be install …
- I would really like helps the Plug’ins have been available to “textpattern.net” to get a better idea of plug’in, without having to install it.
- And to have for every plug’in its FAQ page, which allows the creator of plug’in centralize the answers to the questions most frequently posed on the forum thread
Offline
Re: Textpattern.org v3.0 project
sacripant wrote:
- I would really like helps the Plug’ins have been available to “textpattern.net” to get a better idea of plug’in, without having to install it.
- And to have for every plug’in its FAQ page, which allows the creator of plug’in centralize the answers to the questions most frequently posed on the forum thread
+100
And taking that a step further, which I’ve already spoken to the powers that be about, is a way for collaboration on the plugin docs.
The big gap in plugin help workflow that has always existed is the lack of curation of the 10% of solid content scattered among the 90% of page after page after page of forum noise. With a collaborative doc tied to each plugin in the new repo, people could then maintain a single, concise documentation for each plugin, pulling the juicy pieces out of the forum threads as it goes along, keeping the document relevant and current. Content curation at it’s finest.
Whether or not that’s possible in .net, I can’t say, but if the wiki could serve as a tool for that link between the two sites, it’s available.
Offline
Re: Textpattern.org v3.0 project
-1.
I offer access to plugin help and code through my own website (no need to install the plugin first).
I think TXP.org (v3) could do the same if plugins were hosted (or at least cached) there, but documentation should primarily be done in the plugin help. That’s why it exists.
Offline
Re: Textpattern.org v3.0 project
Fair enough. There’s always degrees. Some devs are great about maintaining docs, others not. And let’s not make light of the ability to write tech information clearly.
Maybe some optional path is appropriate.
It’s not just about the base documentation, though, but other goodies get lost in long threads too, like what others do with the plugin, or useful mods they make, etc. Do you maintain that kind of thing at your site too?
Sacripant makes an interesting case. He’s not just some guy with an opinion like me, he’s a person saying, due to language, he’s unable to use the forum threads because of the noise he has to wade through. (And I know he’s not alone.) We should make the process better. It can always be better.
Offline
Re: Textpattern.org v3.0 project
I feel sacripant’s pain, to a lesser degree of course. That’s why the core idea behind this is, as Destry says, to bring curated content directly to the plugin’s page. This content is secondary to the documentation, but of equal importance for end users. The idea behind it being collaborative is that it allows anyone to add any of the following (non-exhaustive) items into one location:
- A link to a forum post that highlights an important mod required to run on Txp X.Y.Z (think rss_db_admin_manager) or some important info that would otherwise be buried
- A link to a known issue on an issue tracker to help deflect unnecessary bug reports
- A link to a third party script that might be of value — a jQuery plugin / gallery for example that others can use straight away, knowing it will work with the plugin
- A link to a TxpTip that demonstrates the plugin in action
- Links to community-hosted Textpack translation files
If that information was available at your fingertips on the plugin page it’s a powerful and useful tool to consolidate key info about the plugin. My initial thought was to have people add such links directly and have them stored as standard Txp links so they can be ordered, etc by the author. But I was struggling to keep spam out and it put unnecessary strain on the plugin author to keep it valid and up-to-date — something that I wanted to avoid as the idea is that the repo is as hassle free as possible for plugin authors to maintain.
Destry threw me a curve ball the other day and suggested using some online central repo like a GoogleDoc (not my first choice, btw, as I’m not a huge fan) or equivalent tool such as our own wiki that allows anyone to edit the contents. The only thing we need to do then is specify a loose template so that people get used to knowing where stuff is in that document. The plugin repo then has a single link to that ‘supplemental info’ and it’s maintained by everyone with a vested interest in that plugin. Perhaps longer term we could suck key points out of this document via XML (or something) and show them directly on the plugin’s page, but that’s a lot further down the line.
To answer Ruud’s point about documentation, when you publish a new version of a plugin to .org (manually in Phase One; optional automation in Phase Two) and it builds the changelog for you, one of the things I hope to do is actually fetch a copy of the plugin .txt file and cache it in a custom field (probably a glz_cf textarea). This serves two important goals:
- If someone clicks on a plugin download link and it 404s, the cached “Last Known Good” copy can be served instead (I’d love to be able to do this automatically and seamlessly in one click — perhaps by ‘fetching’ the HTTP header first to check its status and, if valid, continue to the author’s site to grab the .txt file, else serve the cached version. Not sure if that’s possible though: any technical gurus out there who can offer advice here please let me know)
- (as ruud says) Having a cached version of the plugin means that documentation is available directly without needing to install the plugin. I do it on my site, ruud, net-carver, Gocom and Adi do it and I know others do too. But to have it on the .org site as well might save people downloading a copy of a plugin that doesn’t fit their needs (and thus makes download counts more accurate!)
I hope that sheds more light on the direction we’re heading and makes sense. Any other thoughts please share them.
I’m going to talk with Destry later about perhaps using the wiki as the central location for plugin curated docs. I’m not sure what’s possible there, nor how to set up templates and stuff. It might be a non-starter, or it might be the start of something beautiful.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline