Do we need a plugin repository?

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…

benbruce · 2006-03-30 05:13:41

Make sure you’ve written documentation for it before you release it.

Skubidu · 2006-03-30 07:08:18

Sencer schrieb:

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…

That’s exactly what I thought, too, as I was reading this thread. In my opinion it is very easy to develop plugins for TXP (even easier since there is this plugin). There are actually some problems for the end user: How to find a plugin? Where to find a plugin? How to know if it works with the version of Textpattern I use? I’m not convinced that SVN would help with that because it’s not very intuitive for somebody who is not a programmer.

I think there is the need to have a central place¹ where you can download the plugins (like Mozilla’s Addons) that looks like a normal website (and not like a freaky coders corner ;) and is more clearly arranged that “textpattern.org“http://textpattern.org is now. I don’t know if something similar is possible for textpattern plugins, but I really like these install buttons on the mozilla site. It’s smart and simple: Just click it and the extension will be installed.

Nils

¹ It should be central to be sure that plugins are not lost if the developer switches to an other CMS and doesn’t support the plugin anymore (often there isn’t a download anymore at some point).

Andrew · 2006-03-30 16:18:20

I just don’t see plugin devs maintaining a copy of their plugin in more than one location. I have mine under subversion and uploading it somewhere else would just make the process that more difficult: anytime I have a small update I’d have to commit changes, update the working copy, and then upload it again somewhere else.

The more I look at textpattern.org, the more I think it is a good solution. It just needs a little bit of love (redesign) and some community hands.

mrdale · 2006-03-30 18:18:29

Sencer wrote:

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

Let me give you a use profile: The web-developer who routinely locates, downloads and updates the latest versions of many plugins, from diverse remote locations for one of many given installs.

Today it took me about an hour to perform the above task, and I’ve done it before. When I compare that, with a single SVN command to update my TXP install I starting thinking.

I started thinking about setting my own mechanism to avoid starting from scratch each time. Something as primitive as a preconfigured TXP base install, or as complicated as my own personal TXP svn repo…

Perhaps there are very few other end-users with the same challenges. I’m certainly not trying to create additional work, or ask someone to build something for me. Just thinking of a more streamlined, automatic and dynamic way for the end-user to interact with plugins, the part of TXP installs that changes the most.

Perhaps “elements” are intended as a stop gap here, but I have no idea how they are going to behave.

BTW: I greatly appreciate Resources and Textbook. I just think there has to be something more automatic, integrated and focused on plugins

Anyway. Just ideas.

Andrew · 2006-03-30 18:47:30

Doesn’t Firefox use an rdf methodology for updates? Within the extension is the address to an rdf file that contains update information for the plugin. Once again, no idea how feasible this would be for Textpattern, but it’s sort of a middle-ground solution that would allow devs to maintain control of their files, while also providing the end-user a means to check for auto-updates.

{edit: I just read wilshire’s previous post and the difference would a dev maintaining the update rdf for each plugin vs a centralized RSS file that would probably be unmanageable unless someone came up with a really clever solution.}

Last edited by Andrew (2006-03-30 18:50:09)

akokskis · 2006-03-31 17:53:31

I think that a lot of clever and good ideas are being posed here, however we still have a number of issues that will most likely, at least in my opinion, stop such a project from really occurring.

The complexity of organizing all the plugin devs to use one site would be a huge task. As well, for those who don’t use SVN for their plugins (I for one do not at this time, although I’m planning on moving to it at some point), it would be just another hurdle in the way of the actual plugin development.

As for some way of seeing whether or not plugins have been updated through the txp interface, I think that it’s a good idea, however I would think that it’s not going to be possible on all the different possible server configurations that are out there. I’m sure some servers don’t have / don’t allow the use of CURL, so then what? I think that the problem here is that txp should stay such that it’s useable with not much messing with the actual server side of things, if that makes sense.

Don’t get me wrong – I do think that some way of knowing when / if plugins have been updated would be a great help, but I just don’t really see it happening with all the different factors playing into this, making it such a complicated thing to actually do.

Textpattern CMS

Textpattern CMS support forum

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

#25 2006-03-30 05:13:41

Re: Do we need a plugin repository?

#26 2006-03-30 07:08:18

Re: Do we need a plugin repository?

#27 2006-03-30 16:18:20

Re: Do we need a plugin repository?

#28 2006-03-30 18:18:29

Re: Do we need a plugin repository?

#29 2006-03-30 18:47:30

Re: Do we need a plugin repository?

#30 2006-03-31 17:53:31

Re: Do we need a plugin repository?

Board footer