I've just started installing plugins on my site and was horrified to see the number of scripts being added to /bin - at this rate with only a few plugins installed there could be a multitude of of bin program name clashes and, of course, mass confusion when trying to unpick the mess.

Perhaps we can consider making a standard that plugins should install any associated scripts into a directory such as /bin-plugins/PluginName/scriptname?

Ta.

-- MartinCleaver - 02 Apr 2002

Probably the proliferation of scripts comes from the current state of the plugin API. More hooks are need, until now a plugin had to replicate the scripts to handle its peculiar handlers.

I suggest that the plugins developers analyze their plugin and suggest the handlers that would make unnecessary (if possible) their scripts.

I agree that the remaining scripts related to plugins would be better placed in a subdirectory of bin: e.g. bin/PluginName/scriptname

In the same directory should be placed the corresponding .htaccess file to properly handle access to the script.

-- AndreaSterbini - 04 Apr 2002

In terms of scripts in bin, I suppose you could have a central, handling script that passed down the request. So perhaps bin/callplugin called as bin/callplugin/PluginName/scriptname which calls down to lib/Plugins/PluginName/binscripts/scriptname.

The callplugin should at least provide some parameter security checks. It is also a nice place to put further functionality.

I think that analysis of the existing plugins needs to be done by a dedicated team member. Its its an architectural task that is too complex for people to coordinate distributively, at least in the short term.

-- MartinCleaver - 05 Apr 2002

I think the best solution is to remove the need for plugin scripts in bin, as suggested by Andrea - e.g. you could have a special plugin call that causes a generic plugin script to call a specified plugin routine very early on, effectively running the same code as is currently done in a script in bin (this is actually JohnTalintyre's idea). This would be much cleaner than having per-plugin scripts in bin.

-- RichardDonkin - 05 Apr 2002

Well, one idea I have been playing with whilst reviewing for FatCgiScripts is the idea of a CommonFrontEndCgiScript.

See also MegaTWiki; PeterNixon says that it has a single script mega that might fulfil the role we talked about here.

-- MartinCleaver - 01 Jul 2002

Re: Andrea's comment above regarding plugin authors analysing API requirements. I tried that, and didn't get any response from the core team (see PowerEditAddonDev)

In my case most scripts could be eliminated by the simple expedient of moving the code in the scripts to where it should be - in the .pm's. No script in bin should need to be more than a single function call.

If you wanted to be really purist you only need one script in bin; all the twiki functionality could be accessed through it (twiki/bin/twiki/Main/WebPreferences?function=view) and plugins as well (twiki/bin/twiki/Main/WebPreferences?function=PluginName.view).

• This is exactly what I meant by CommonFrontEndCgiScript - MC 16-May-2003

-- CrawfordCurrie - 02 Jul 2002

Crawford, I am sorry for my lack of answers on the plugin extensions ... I'm too loaded now to follow everything ...

-- AndreaSterbini - 02 Jul 2002

-- MartinCleaver - 16 May 2003

Single script with all the functionality of Twiki - looks like CGI::Application module to me. C::A community was even interested to develop an wiki example of using best practices of C::A. CgiWiki is going there, so there is going to be CPAN archived C::A based wiki. And quite soon it might be the most popular perl wiki.

-- PeterMasiar - 16 May 2003

Plugins can use REST handlers to remove the need to have a script in the bin directory.

-- RafaelAlvarez - 25 Aug 2008