Item9974: setlib.cfg loaded twice but LocalLib.cfg only once
Priority: Normal
Current State: Closed
Released In: 1.1.2
Target Release: patch
Applies To: Engine
Component: Configure
Branches:
I just created a fresh foswiki 1.1.1 setup in order to migrate my old 1.0 content to it. I'm using a non-standard directory layout with the bin directory outside the tree. According to
the install guide this should be supported. However, configure greeted me with an empty page.
The reason took some time to uncover. It seems that
=TemplateParser.pm= is to blame. There you have the following code:
# This is probably slow, but we need to know where the templates are
our $foswikiLibPath;
unless ( defined $foswikiLibPath ) {
delete $INC{'setlib.cfg'};
eval { require 'setlib.cfg'; };
}
$foswikiConfigureFilesDir = "$foswikiLibPath/Foswiki/Configure";
setlib.cfg
was loaded by the cgi script
configure
. It in turn loaded
LocalLib.cfg
which then set foswikiLibPath. Now this code above requires
setlib.cfg
again. It forces reloading by deleting some hash item first.
setlib.cfg
doesn't do the same for
LocalLib.cfg
. Therefore
LocalLib.cfg
doesn't get loaded again, therefore
setlib.cfg
falls back to
../lib
for the library path, which is wrong in my case.
All of this second loading stuff seems like an attempt to deal with scoping. The original initial loading of the mentioned files happened outside the scope of any explicit package, and therefore in the scope of the
main
package. Later on, the variable is referenced inside a package and therefore scoped to it. I guess the best approach would be dropping that double-loading stuff and using
$main::foswikiLibPath
instead.
One method would be this:
# This is probably slow, but we need to know where the templates are
our $foswikiLibPath;
if ( !defined $foswikiLibPath && defined $main::foswikiLibPath ) {
$foswikiLibPath = $main::foswikiLibPath
}
$foswikiConfigureFilesDir = "$foswikiLibPath/Foswiki/Configure";
Another would be something form of global import of that variable, but I'm not sure about the appropriate syntax just now.
--
MartinVonGagern - 08 Nov 2010