Do we need a plugin repository?

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)

juanjonavarro · 2006-02-08 09:08:43

A lot of things going in this thread.

licensing:

I think that every plugin is licensed GPL by definition (because TXP is GPL).

local repositories:

Maybe the solution is for Textpattern Resources to maintain a local copy of the plugin or to create a new website with plugins.

textpatternforge:

A good idea. A place where plugin developers obtain development resources (svn or cvs, web space, etc).

hakjoon · 2006-02-08 14:21:57

Champak wrote:
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.

I don’t think you can really knock it until you have tried. I think you will find most of the plugin developers are a pretty friendly bunch who will gladly take suggestions and input on how to make their stuff better.

My suggestions were not meant to imply that there should not be better docs/help but suggesting ways in which you could help make make things better.

“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.

No, but if someone contacted me with better help files I would totally include them and I’m sure others would 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.

Sorry I meant followed up the threads. I know I subscribe to all my plugin threads so if someone posted saying that something could be explained better and provided copy I would try to incorporate it

Remember that this is strictly volunteer, so calling bull on someone’s claim of not enough time/interest is not going to make that change, what is likely to happen is that someone will simply stop sharing their plugins.

takshaka · 2006-02-08 18:08:22

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

You’re approaching this with a tremendous sense of entitlement. If a plugin author wants to throw out something with no documentation whatsoever, that is his prerogative. It is your prerogative to not use the plugin, or to help improve the documentation. As hakjoon says, if a plugin author feels his work isn’t appreciated or that end-users are too demanding, he is likely to just take his ball and go home.

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)

It’s a lot easier to answer a specific question than to document every possible question. The more complicated a plugin becomes, the more this is true. And it isn’t like we don’t see questions asked that have already been answered in the docs.

But primarily what I see, both for my plugins and others’, is people submitting bug reports or feature requests, neither of which can be resolved through a comprehensive help file.

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

I think this, at least, is one thing we can all agree on.

mrdale · 2006-03-30 02:28:06

Let’s revivie this discussion about plugins and svn repos and find a way of getting an SVN repository for plugins. I’m tired of doing the plugin hunt every time.

Last edited by mrdale (2006-03-30 02:29:56)

Andrew · 2006-03-30 02:52:19

A centralized, trac/svn site (similar to wp) is the only goal that seems really robust and I believe is totally within reach. I mean, wp-plugins.org is entirely hosted by TextDrive, and if it’s been done once it can be done again. I feel no shame in following wp’s lead on this; it’s a pretty good model to use as a guide.

One major obstacle (as previously mentioned) is that Textpattern’s plugins are stored in the database. This would not allow for users to check out plugins from the central repository, which is why I suggested a method of developing a “Check for plugin updates” feature. However, I have no idea how feasible it would be developing an update system versus changing Textpattern’s plugin system to allow for both compiled and hard-file plugins.

That doesn’t really address plugin developers who are either not savvy enough to grasp subversion or who prefer to keep their plugins under their own personal version control. I’m not really sure what to do about those… if a plugin update check is feasible, these plugins would not be able to take advantage of it.

As to the fate of textpattern.org, while it’s nice that its built with Textpattern, in all honesty I don’t really see its current incarnation as being adaptable enough for the demands that a plugin resource demands. I do believe that the domain should remain the resource hub, but that would require convincing alicson to allow for someone(s) to get in there and get a little crazy on that domain (also hosted on TextDrive). That is, of course, after a clear plan is established.

Sencer · 2006-03-30 03:40:42

Which/Whose problem(s) are you solving by offering a central svn-repo?

IMHO mentioning wp-plugins.org is actually making a case against the idea, because I just don’t see how that has worked out all that well – neither for the people writing a plugin, nor for plugin-users looking for plugins. Maybe it has helped people who are looking for abandoned plugins… but that’s not the best target group to pick/serve. In this context* (IMHO) Trac is not solving the interesting problems, and those problems that it tries to solve, it doesn’t solve well (again, only within this context – for other purposes it may be great). If there was zero maintenance with svn/trac I could see, why someone would push the idea (“low hanging fruit”), but not even that is the case, as accounts require manual interventions and are not automated.

*Now of course we can argue “what is the context”. Hence my question in the beginning of the post: Which/Whose problems are you trying to solve? It is my impressions that plugin-developers generally have what they need to be productive. It is mostly plugin-users that feel lost or can’t find what they are looking for…

Andrew · 2006-03-30 04:07:45

Which/Whose problem(s) are you solving by offering a central svn-repo?

Hm… well, that’s a good question.

To be honest, I’ve never had a problem as a plugin dev since the plugin_cache_dir and I follow your reasoning behind more-trouble-than-its-worth. Now that I think about it, svn/trac would be tough to maintain and would likely fall into disrepair.

So that brings us back to documentation.

Mary · 2006-03-30 04:29:38

…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…

Would it be fair to say that your frustration might be causing you to place blame on someone else, anyone else, rather than take the extra time to learn something new?

Properly maintained and documented plugins continues to be nearly thankless job. Guess why I don’t do it anymore…

wilshire · 2006-03-30 04:57:35

I toyed with a solution for this a while ago that used a custom RSS feed published on textpattern.org.

The feed included all articles from the plugin section and included each plugin’s name, version, description and download URL. There was then an admin plugin that would be installed on a TXP site that would parse that feed and build a listing of plugins on a new tab in the TXP admin. From there, you could pick a plugin and click a button to install it. The plugin would then use CURL or something similar to hit the download URL, pull back the plugin code and install it.

The benefit was that the plugin was on each authors site, rather than in a central location but the feed exposed the location of each plugin file. I got this to the point where it actually worked and I could successfully install plugins on a TXP installation from a remote location.

I don’t think the plugin is far off from being usable, but you know how things go. The first 90% is the easy part, its the last 10% that takes the most time…

Textpattern CMS

Textpattern CMS support forum

#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?

#16 2006-02-08 09:08:43

Re: Do we need a plugin repository?

#17 2006-02-08 14:21:57

Re: Do we need a plugin repository?

#18 2006-02-08 18:08:22

Re: Do we need a plugin repository?

#19 2006-03-30 02:28:06

Re: Do we need a plugin repository?

#20 2006-03-30 02:52:19

Re: Do we need a plugin repository?

#21 2006-03-30 03:40:42

Re: Do we need a plugin repository?

#22 2006-03-30 04:07:45

Re: Do we need a plugin repository?

#23 2006-03-30 04:29:38

Re: Do we need a plugin repository?

#24 2006-03-30 04:57:35

Re: Do we need a plugin repository?

Board footer