Question

For some reason TWiki is not recognizing my plugins.

I am trying to get the CommentPlugin to work. I installed it.

Because I do not have control of the webserver I have installed it on, I followed the alternate install directions --

• the bin/ scripts in /home/madebeer/www/cgi-bin/
• the lib/ files in /home/madebeer/www/lib/
• the data/ files in /home/madebeer/data
• the templates/ files in /home/madebeer/templates

Twiki does not recognize the plugins in my

• /home/madebeer/www/lib/TWiki/Plugins directory

I can see that in TWikiPreferences the * Currently activated plugins is only DefaultPlugin

But I can see in the directory that both InterwikiPlugin.pm and CommentPlugin.pm are there.

Thanks for your help

• TWiki version:20011201
• Web server: Apache
• Server OS:linux
• Web browser: galeon
• Client OS: linux

-- MichaelDeBeer - 07 Mar 2002

Answer

I believe (I might be wrong) that you need to create Plugins web and create CommentPlugin page there. I recall I was not able to activate this excellent plugin before creating page for it. Again, it might be something else.

-- PeterMasiar - 08 Mar 2002

I tried Peter's advice, but it did not work. So I edited TWikiPreferences and manually added CommentPlugin to the list of InstalledPlugins and now it works.

-- MichaelDeBeer - 07 Mar 2002

I had the same problem with TWiki on SF once I tigthened up the security.

The reason for this is that TWiki::getTWikiLibDir() tries to build an absolute library path from @INC at init time. getcwd() fails if one of its parent directories is not readable (when executed by the cgi user)

The solution is to pre-initialize the library path in TWiki.cfg:

# this should not go into the release, it fixes the problem of
# getpwd() returning null because of parent directory permission:
$twikiLibDir      = "/filepath/to/your/twiki/lib";

-- PeterThoeny - 08 Mar 2002

-- MichaelDeBeer - 08 Mar 2002

There is now another possible solution for this (not tested), which is to use setlib.cfg to define an absolute pathname for $twikiLibDir, which will avoid the problematic code from being executed. This avoids editing the main code and should be easier for future upgrades - see SettingLibPath, which is in TWikiAlphaRelease as of today.

A related question - since $twikiLibDir is only apparently used in Plugins.pm to list the TWiki/Plugins directory, why is it important to use an absolute pathname for this? After all, if you can access ../lib in order to run TWiki.pm etc, you can also access ../lib/TWiki/Plugins (or at least the .. is not causing any problems). So, I can't quite see why normalising $twikiLibDir is necessary. (I know this is a Codev issue, but it's only a small one )

-- RichardDonkin - 03 Aug 2002

Just thinking out loud, what happens if your current working directory changes because of a plugin or something? Will ../lib still work? The fully qualified path will still work.

-- JohnRouillard - 05 Aug 2002

Good point - however, I remember changing directories broke something else recently, so it might be better to just make sure plugins don't change directory, avoiding the whole problem of trying to find the absolute path in an efficient way.

-- RichardDonkin - 07 Aug 2002

Well, the fact is that TWiki itself changes the directory after each search. (The original directory is not restored because of performance, cwd() is an expensive call at runtime.)

That means that Plugins should do a special handling of loading modules if done late (the ChartPlugin does that for example), or the relative lib path should be avoided in the first place.

-- PeterThoeny - 10 Aug 2002

A (perhaps) related question: I am trying to install the TreePlugin on a hosted site. I have been able to install others (SmiliesPlugin and CommentPlugin, for example) but I'm stumped by the twiki/lib/TWiki/Plugins/ subdirectory. I tried putting these files in the same subdirectory as TreePlugin.pm itself, but the plugin wasn't activated. Any thoughts or pointers? Thanks.

-- JimLevin - 29 Aug 2002