Do we need a plugin repository?

juanjonavarro · 2006-02-07 16:25:55

There are some plugins that are not accessible anymore. Maybe the author is not maintaining the plugin and deleted the plugin code from his website.

We have Textpattern Resources and this forum, but these are still linking to the author’s website. Do you think we need a plugin repository maintaining local copies of the plugins?

Best regards.

Andrew · 2006-02-07 17:11:33

svn.textpattern.org ?

Champak · 2006-02-07 17:14:37

I think this is definitely needed. I’ve only had this thing for about a week, and I’m tired of coming across dead links to plugs, posts that do not have the updated plugs, people taking over plugs and there is no links to those. I think the whole thing is discombobulated as is.

2/ I ESPECIALLY think people should learn to write descriptions a lot better than they are currently doing. It damn well takes me reading the descriptions 4-6 times to truly understand what the hell the things do, and even then, I sometimes have to install the thing to completely understand. I have other programs installed that use plugs/mods with WAY better and clearer descriptions. And they are not necessarily longer either. Hell, I’ll write your descriptions.

3/ I also think it would be nice if there was some kind of update notice with the plugins that would ping the admin panel where the plugs are listed to notify of updates to the plugin. This would definitely be able to happen if the plugs were maintained here.

4/ The help manuals to the plugs need to be a little better. Some of the developers here seem to write the manuals for the people who already know how to use this thing.

And all of this could be handled by one person. Either a developer of textpattern or a volunteer, it doesn’t take an army. I would volunteer, but I don’t know enough about this yet.

I know I’m new, but my 2cents.

hakjoon · 2006-02-07 17:51:23

Have you thought of contacting the plugin author and offering better descriptions? Have you followed the threads with descriptions better describing the functionality? Have you offered better plugin manuals?

All the things you describe take time and sometimes the developer doesn’t have time. Remember that most of the plugins are created because the developer needed the functionality. He/she knows how the plugin works, therefore instructions are not seen as necessary. Someone who uses the plugin and finds it useful is always welcome to provide better docs for it.

That being said I would love to see a central plugin repository with SVN accounts for developers kind of like what Drupal and CMSmadesimple offer. A textpatternforge if you will, but someone with resources for something like that would need to step up.

Manfre · 2006-02-07 18:00:37

With regards to descriptions, you should write up a description and send it to the author, or post it to the thread if you are so dedicated. As a plugin author, I spend my limited free time working on plugins. Would you rather have fewer, well documented plugins with less functionality, or have things the way they are?

Andrew · 2006-02-07 18:04:03

hakjoon wrote:
That being said I would love to see a central plugin repository with SVN accounts for developers kind of like what Drupal and CMSmadesimple offer. A textpatternforge if you will, but someone with resources for something like that would need to step up.

Agreed.

akokskis · 2006-02-07 18:48:54

I’m going to have to agree that as a dev, I’m a hell of a lot more likely to be working on the code rather than adding better or more clear help text. Plus, if someone posts to the topics in this forum for my plugins, or on my personal site, I make every effort to get back as soon as possible, and if I don’t, it’s quite likely that someone else who uses one of my plugins will help said person out.

I’d much rather spend my time coding. That’s why I’m a comp sci major, not an english major. If people wish to help the progress of my plugins, I’m more than happy to accept their help and take the new help text or whatever and integrate that into my plugin.

If you need some help, just ask on the forums. People in this community are very nice and helpful, so probably you’ll get a good response rather quickly.

Andrew · 2006-02-07 19:39:45

I think creating a plugin repository is completely unrelated to improving plugin documentation. Yes, many plugins could have better docs, but the forum remains a damn good place to discuss and ask questions about plugins.

Creating a subversion repository for devs would likely be a good thing. But the way Textpattern plugins are installed would not allow Textpattern users to benefit too much, except for perhaps a revision update feed. Since Txp plugins are installed into the db rather than just droped into a /plugins directory, end users wouldn’t be able to just svn co http://svn.textpattern.org/your-plugin/ to keep their plugins synced with the current revisions.

Ideas?

The Human Museum · 2006-02-07 19:50:50

Just a fly on the wall here, but the sooner the developers and end users can find some middle ground between code and usability/documentation/information consolidation, the sooner Textpattern will be embraced by a larger market. The Textpattern learning curve is pretty steep – you can’t blame the end users trying to consolidate the information out there and cut down on the hurdles. I myself tried and abandoned Textpattern a few times because I felt over my head. As great a resource as Textpattern Resources is, I think juanjonavarro is right – there needs to be some sort of permanence.

hakjoon · 2006-02-07 21:05:26

Andrew wrote:
But the way Textpattern plugins are installed would not allow Textpattern users to benefit too much, except for perhaps a revision update feed. Since Txp plugins are installed into the db rather than just droped into a /plugins directory, end users wouldn’t be able to just svn co http://svn.textpattern.org/your-plugin/ to keep their plugins synced with the current revisions.

It definitely would not work just for checking it out through svn but if a working copy was updated automatically you could setup a system with zem_tpl.php in the include path so that whenever someone went to download the plugin it would get compiled and the compiled version would get presented to the user. A svn repo could allow for more collaboration between plugin developers and the code for a plugin would never disappear. zem_tpl.php will work like that already without any modifications I think.

Andrew · 2006-02-07 21:07:26

Yes; a ‘Check for plugin updates’ feature built into Txp admin would absolutely kick ass.

placenamehere · 2006-02-07 21:41:30

I’d be interested in the direction this takes on… but I see some big issues that would need to get sorted

cooperation from plugin devs
licensing issues /conflicts
the manpower to police the thing – get new authors to include their stuff – admin transitions of ownership, etc
versioning issues and conflicts — and other dangers of automagical updates

As an author of just one plugin so far myself I’d also be cautious about the lack of flexibility the “normal” interface would offer… since i’m currently offering usage examples, extra css downloads, and some other info on the designated page on my own site. (not to mention ads, which in my case is negligible impact and not something i’m concerned about, but others might be more protective of that kind of stuff)

As to the documentation side of things I think one of the things tht a non-“developer” could really help with would be writing a good help template for plugins — create examples of good descriptions, help text for a plugin, for an entry in the textpattern resources site, etc. — and then get them used by having them included in things like zem’s plugin template so that the act of including good help info becomes a brain dead task for developers.

Anton · 2006-02-07 21:59:23

Wouldn’t it be cool/useful to have an interface that works pretty much the same as zem’s plugin template? You could have one textarea for the php code, others for the plugin name, author, help text, etc. And then click “generate plugin” to create a txt file/output with the MD5’ed plugin code. Would be easier to maintain too, I guess – just login, edit and regenerate (autoincrement on version numbers after each edit of course, preferably with a comment field for what was added).

Am I making sense?

placenamehere · 2006-02-07 22:24:59

I just can’t see that level of automation working. It would need to allow for distibution of other files (license files, templates, css), building a package that could be tested independantly of being released. be easy enough to use when building and testing locally, etc. etc.

No, I think you’re better off defining a broader pacakage contents (plugin.txt file + other stuff) and having authors upload revisions as they release…

that or having a standard package template and managing svn along with a scrip that creates the distributable package from svn rather then some piecemeal web form. I’d actually think an interface like you’re describing would be detrimental to attempts at well documented plugins becuase it would encourge people just to fill in the change notes or the documentation changes at the point of distribution / on the fly rather then reinforcing that its part of the codebase that needs to be maintained and changed along with the php stuff.

fwiw… the way i’m working now…

run a local svn repository for the project
code changes
package plugin
install on dev server
if code seems ready and I have no more revisions then install on my own sites
if things are stable there and i’ve finished all the features i’m intending for my next release then I release the next version with the same package that I created and installed on my test server.

Champak · 2006-02-08 07:14:33

“No time” = Bull!
“Busy coding” = Lazyness!
“Originally made it for yourself” = So what!

The time some of these developers take going back and forth answering/resolving issues in the forum, 1/8 of that time could have gone to giving a better explanation/manual and thus eliminating a good number of back and forths in the forum.(that way you’ll have more time coding)

hakjoon:
“Have you thought of contacting the plugin author and offering better descriptions?”
No, and it’s a good suggestion, however, if someone didn’t put in any time to initially put in the info, or adjust/add info to it based off of discussion threads, I HIGHLY doubt that they would be inclined to adjust based on what I send them. For all that they could just extract from their answers in the forum.

“Have you offered better plugin manuals?”
I didn’t know I could do this. Are you telling me that I can put a manual inside the plug in help and reupload the plug in? Because that is where I’m talking about the lack of info is. I’d be willing to do that once I learn this stuff. ……but I am also talking about the info at the download spot as well.

“Have you followed the threads with descriptions better describing the functionality?”
The time it takes to read through everybody else’s problems 1/16 of that time could have been taken to read through a better help file and solve it. And again, the time that the developer took to answer all those question could have gone to writing a better help file, and initial explanation.

akokskis:
“I make every effort to get back as soon as possible, and if I don’t, it’s quite likely that someone else who uses one of my plugins will help said person out.”
That’s my point, I don’t want to have to come across the “if I don’t” part if you are still a part of this community(I say that because I know sometimes people move on to other things). People here may very well be very nice people, but responses to questions are lacking or VERY slow here. (this is in comparison to other places I’m a part of).

The Human Museum:
I agree totally and that’s exactly why I have said what I said. It’s been 6 days since I’ve installed this thing, and I’m just getting it and starting to flow around it in a decent manner. I’m usually flowing seamlessly around programs by the 3 day, and that is coming from commerce carts, complex ad scripts, forums, cms, and membership scripts.

placenamehere:
“cooperation from plugin devs”
That’s not a problem, it’s just a matter of setting a coding standard. Just like you have to put “script” at the beginning and the end of a javascript, is the same way you have to put a particular piece of code in the script to submit it.

“licensing issues /conflicts”
I personally think the whole licensing thing is stupid with stuff like this. I understand the pride in putting some of this stuff together and the knowledge that it is “yours”, however to act like it’s some major code for Microsoft or a major software that is collecting money is ridiculous. Solution is simple, you submit it, you give authorization to use it. No conflicts. Fair and easy. I mean, why are/do/will people complain about something like this if they want to “participate” and “help”.

“the manpower to police the thing – get new authors to include their stuff – admin transitions of ownership, etc”
1/ Manpower…you submit a code and wait for it to be approved and added. What manpower? I assume that’s how it is done now.
2/ If you set the standard, people are going to abide and submit. It’s not like you have to convince them to include their stuff. People don’t just submit and post to help, they also submit for pride.
3/ My previous about licensing I think takes care of the last part.

Now this isn’t to all developers, some have decent to very good help files and initial explanations, and some have been extremely helpful, even with personal emails, but that is a 50% ratio, and I don’t believe a 50% ratio is a good number. The way I look at it is if they can do it, others shouldn’t complain about being unable to do it(rss, zem, glx are examples of great developers, if they can provide comprehensive help files with as many plugs as they do, others shouldn’t have a problem). I am a none coder and wouldn’t mind helping where I could, but I believe it is the developers DUTY to COMPLETE their package. Now I may be spoiled, because I’m coming from other scripts that have far better documentation with their plugs/mods and description/help files, but I just believe it is right. Now REMEMBER, I don’t necessarily mean write a 10 paragraph description and help files, one and two sentences are good, but be clear.

People always make excuses of why not to do something rather than seeing why they should do something. Positions of that nature will never make a situation/program/community better than alternatives, and could/will hinder growth. And then what is the point?

All and all, it is a great program. I actually left wordpress for this and am relatively happy, these are just observations and suggestions so don’t take offence.

P.S. another thing that is really lacking is screen shots. Hell the screen shots would make up BIG time for the coders that apparently “don’t have the time” to complete their plug ins.

P.S.S Why aren’t plug ins deleted from the repository that have been included in the program….that excluding the ones that have an extra feature that is not included in the program. It’s a headache grabbing an old plug that is already included or similar features incorporated in the program and learning about it later.

I’m sure some are going to hate me, but if no one speaks, nothing changes. Cheers all. Sorry for the length of this post.

Last edited by Champak (2006-02-08 08:21:47)

Textpattern CMS

Textpattern CMS support forum

#1 2006-02-07 16:25:55

Do we need a plugin repository?

#2 2006-02-07 17:11:33

Re: Do we need a plugin repository?

#3 2006-02-07 17:14:37

Re: Do we need a plugin repository?

#4 2006-02-07 17:51:23

Re: Do we need a plugin repository?

#5 2006-02-07 18:00:37

Re: Do we need a plugin repository?

#6 2006-02-07 18:04:03

Re: Do we need a plugin repository?

#7 2006-02-07 18:48:54

Re: Do we need a plugin repository?

#8 2006-02-07 19:39:45

Re: Do we need a plugin repository?

#9 2006-02-07 19:50:50

Re: Do we need a plugin repository?

#10 2006-02-07 21:05:26

Re: Do we need a plugin repository?

#11 2006-02-07 21:07:26

Re: Do we need a plugin repository?

#12 2006-02-07 21:41:30

Re: Do we need a plugin repository?

#13 2006-02-07 21:59:23

Re: Do we need a plugin repository?

#14 2006-02-07 22:24:59

Re: Do we need a plugin repository?

#15 2006-02-08 07:14:33

Re: Do we need a plugin repository?

Board footer