NOTE: If you are a developer, please use a private wiki based on foswiki/trunk on a daily base ...or use trunk.foswiki.org to view this page for some minimal testing.
Use Item9693 for docu changes for 1.2 and 2.0.

Item2595: extender.pl fails if plugins are misbehaving

Priority: CurrentState: AppliesTo: Component: WaitingFor:
Normal Confirmed Engine Configure  
  • Install BlackListPlugin
  • Delete System topic
  • Get "use of uninitialized value on line 150" error (See Item8379)
  • Try to use configure to re-install BlackListPlugin
  • extender.pl fails with this error:

Error: Installer returned errors:

************************************************************
Could not load /srv/www/vhosts/wiki.org/foswiki-test/tools/extender.pl
There was a compile error: Use of uninitialized value in concatenation (.) or string at /srv/www/vhosts/wiki.org/foswiki-test/lib/Foswiki/Plugins/BlackListPlugin.pm line 150.
BEGIN failed--compilation aborted at /srv/www/vhosts/wiki.org/foswiki-test/tools/extender.pl line 147.

Error when trying to eval the file content: This installer must be run from the root directory of a Foswiki installation at (eval 253) line 112.
BEGIN failed--compilation aborted at (eval 253) line 147.


You may be able to resolve these errors and complete the installation from the command line, so I will leave the installed files where they are. 

-- PaulHarvey - 06 Jan 2010

I think this is a more basic problem.

extender.pl creates a foswiki object ($session = new Foswiki($user);) and this fails because the plugin fails. I wonder if we have the mechanism to create a foswiki object with all plugins disabled?

I would think the best we could do is make sure all plugins are disabled when we run in this mode.

BlackListPlugin naturally should fail differently but then another plugin that we have no control over will do the same later.

I am sure we have had this problem for years. The work around as the failing extender also tells the user is a manual reinstall of the plugin. Not a very serious error but if we can get extender to disable all plugins when it runs we get the whole thing a little more robust to people can repair a screwed plugin using configure upgrade.

-- KennethLavrsen - 06 Jan 2010

See also (JQueryPlugin kills configure): Tasks.Item8783

-- PaulHarvey - 27 Mar 2010

ItemTemplate edit

Summary extender.pl fails if plugins are misbehaving
ReportedBy PaulHarvey
Codebase 1.0.8, trunk
SVN Range
AppliesTo Engine
Component Configure
Priority Normal
CurrentState Confirmed
WaitingFor
Checkins
TargetRelease n/a
ReleasedIn n/a
Topic revision: r4 - 14 Mar 2011, GeorgeClark
 
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. see CopyrightStatement. Creative Commons LicenseGet Foswiki at sourceforge.net. Fast, secure and Free Open Source software downloads