Do we need a plugin repository?

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.

maniqui · 2006-03-31 18:18:53

I cant have an opinion about SVN, update check and all that stuff because it’s very out of my scope and capacity of understanding.

I just want to throw the idea of a new TXP related site: www.textplugins.com
I know we have textpattern.org and it’s a great resource site (maybe http://plugins.textpattern.org ?).

The idea of TextPlugins is a site only related with/oriented to well… Textpattern plugins…
A very simple site.

It could be like our old and beloved “Central Plug-in List” on steroids.

I imagine just only a home page with a very large table with the following columns:
Plug-in name | Version/Last update | Supported since TXP version | Category… what else?

Again, something very simple, a large table.
The plug-ins could be stored inside textplugins.com or if the author prefers, in their own site. The download link will simple link to the url where the plug-in is stored.

Finally, a link from the admin side of TXP to textplugins.com would help to stay up-to-date for news related to plugins.

Yeah, I know… this could be another megamonumental task never finished and regulary outdatted if plug-in authors doesnt maintain it… But it could also be maintained by the community.

Andrew · 2006-03-31 18:22:19

Why not just lend a hand to alicson to clean up textpattern.org?

Mary · 2006-04-01 19:20:17

Yeah, we do have an existing site for this purpose, so we should try to make use of it first.

jesper · 2006-06-20 05:25:59

I am one of these pesky end users who would like to use some of these plugins. And I find it infuriating when you finally find a Plugin that does what you are after that all links to said plugin are dead. Even 6 months old plugins have dead links.

I fully understand and accept that it is up to the plugin coders discretion to decide on the amount of documentation and help they provide with a plugin. But wouldn’t it be reasonable that the community provide a central store for these plugins.

Developers are exactly that. Developers, early adapters, tinkerers and hackers always on the forefoot pushing things further and to the limit. Thus it can be no surprise that they actually change their own sites and structures and occational may loose prior content in the process. In fact they probably do so more than your average Joe Blogs. That is part of the fun and challenge when you are a developer, but wouldn’t it be fair that we provide a memory hole for some of these acheivements before they get lost in the next big thing.

I have run in to piles of dead links over the last two days to the point where I do almost not see any value of textpattern.org. where else on the internet these days do you run into a site with so many dead links? As the plugins are basically just text, couldn’t they be stored in a special article type field along with their description. You could still provide a link to the maintainers version and you could go there to make sure you get the latest version a bit like how download.com has the file locally but also link to the originators site.

Just my 5 cents from someone pissed off with dead links left right and center.

Last edited by jesper (2006-06-20 05:28:42)

Bastian · 2006-06-20 09:26:41

An plugin-svn would be a very nice toy!
But I don’t see its advantage.

Sencer wrote.

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

Thats the point. I would like to work with a svn. I never did before.
But which problems developing txp-plugin would a svn solve? i don’t know.

But nice thread!

Andrew wrote:

Since Txp plugins are installed into the db rather than just droped into a /plugins

I like the txp-“str+c-install-and-done”-style of plugin install.
But often i forget to save plugins i installed and after some weeks i am searching and searching. So i hacked txp_plugin.php and save every plugin i install as .txt
That should be txp-core!

maniqui wrote:

It could be like our old and beloved “Central Plug-in List” on steroids.

That is what i want. A clean simple site including not more than infos from plugin-tab

hakjoon · 2006-06-20 12:21:49

Bastian wrote:
Thats the point. I would like to work with a svn. I never did before.

You should. It changes the way you work. Subversion has everything to get you up and running with a local repository with nothing else required other then Subversion. You should give it a try it’s worth it.

But which problems developing txp-plugin would a svn solve? i don’t know.

I thin the main thing is that it would keep plugin code form disappearing. I think it also makes it easier for developers to cooperate without each one having to setup a public facing SVN repo.

CMS Made Simple did something that I think works well with the CMSMS Forge running GForge Drupal and Ez-Publish also have similar community SVN systems. Basically if you want to develop an extension for the system you get an account which gives you SVN and a bug tracker. Developers don’t need to use them but if a plugin is ever released using the system the code won’t just go missing.

I also think a central repo would make it easier for self updating plugins since the repo can be setup to handle the updates through a common API instead of every developer having to add the upadate mechanism to their site.

Again I think the main benefit is still pugins not disappearing. The rest is just extra bonus.

Textpattern CMS

Textpattern CMS support forum

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

#31 2006-03-31 18:18:53

Re: Do we need a plugin repository?

#32 2006-03-31 18:22:19

Re: Do we need a plugin repository?

#33 2006-04-01 19:20:17

Re: Do we need a plugin repository?

#34 2006-06-20 05:25:59

Re: Do we need a plugin repository?

#35 2006-06-20 09:26:41

Re: Do we need a plugin repository?

#36 2006-06-20 12:21:49

Re: Do we need a plugin repository?

Board footer