I've now withdrawn my previous suggestion, but see /ConfigPrev if you are interested in the ugly design that preceded my current one. That posting resulted in three helpful responses
Something similar is being done in NoNameWiki? a UseMod-derived wiki [1]. It works as follows:
This setup is quite flexible, especially when combined with config variable improvements. For example, the $AdminPass? variable was changed to allow "*" to mean that everyone is an admin. With that it's possible to manage admin access using httpd authentication as follows:
![[Home]](/wiki.gif)
unless ($_ eq 'no_cgi') {
&SetWikiDefaults;
do "$DataDir/config" if ($UseConfig && -f $Datadir/config");
&DoWikiRequest ##NB - RunCGI will be tested below
} # This is the end of all load-time code
Installer Stories
#!/usr/bin/perl # Demonstration of shared wiki code. $_ = 'nocgi'; # Do not run script immediately when loaded require "/full/path/from/root/to/code/dir/wiki.pl"; &UseModWiki::SetWikiDefaults(); $UseModWiki::LogoLeft = 1; # override any defaults here ... &UseModWiki::DoWikiRequest(); # Do the request
#!/usr/bin/perl # Demonstration of shared wiki code. $_ = 'nocgi'; # Do not run script immediately when loaded require "/full/path/from/root/to/code/dir/wiki.pl"; &UseModWiki::SetWikiDefaults(); do "$DataDir/config"; &UseModWiki::DoWikiRequest(); # Do the request
#!/usr/bin/perl
# Demonstration of shared wiki - the following one line
# is the only patch made to wrapper for each site
my $MySite = "BrikiBriki";
#
$_ = 'nocgi'; # Do not run script immediately when loaded
require "/full/path/from/root/to/code/dir/wiki.pl";
&UseModWiki::SetWikiDefaults();
my $FarmDir="/full/path/to/data";
$UseModWiki::DataDir="$FarmDir/$MySite"
do "$FarmDir/config";
do "$UseModWiki::DataDir/config";
do "/some/secure/path/config_onLAN" if $ENV{"REMOTE_ADDR"} =~ /^192\.168\./;
&UseModWiki::DoWikiRequest(); # Do the request
I have redone the configuration system in 2.0. It will be even more bizarre once the script is seen in the context of the MeatBall:WikiAsSourceControlRepository, but much more powerful. I hope it will be easier to use. It's at least easier to code patches for. I will give a basic rundown.
The user provides a list of configuration variables she wishes to set explicitly. This may include any global parameter used by the script anywhere as the namespace will be unified later.
# ................................................... User Configuration
%UserConfiguration = (
DataDirectory => 'c:/sunir/www/db/dev',
SiteBase => 'http://localhost/apps/', # needed for cookies
SiteName => 'UseMod Development Wiki',
HomePage => 'DevWiki',
LogoUrl => 'http://localhost/graphics/crystal/logo.gif',
LogoAlignment => 'right',
);
There is a global parameter hash called %Parameter. This will contain all the in variables for the script, across all UseMod packages. (The out variables live in another hash.) So, for instance, the CGI parameters get sucked into the parameter space:
$Parameter{$_} = $q->param($_) foreach ($q->param);
Of course, we have a shield to prevent the web user from overriding important global variables like the DataDirectory?. (This is just an example. The shield will be module friendly soon.)
# Be more proactive about security; delete any parameters we do
# not want to let the user set.
my $AllowedQueryParameters = qq( action id text keywords );
foreach (keys %Parameter) {
delete $Parameter{$_} unless $AllowedQueryParameters =~ /$_/s;
}
Then we have some variables that the script attempts to determine itself:
my %derivedConfiguration = (
ScriptUrl => $q->url(-full=>1),
PageDir => "$UserConfiguration{DataDir}/page",
);
($derivedConfiguration{SiteBase}, $derivedConfiguration{ScriptName}) = $derivedConfiguration{ScriptUrl} =~ m@^(.*/)([^/]*)$@;
We also have a global hash called %PackageConfiguration, which individual modules use to import parameters into the global parameter space. For example, the RecentChanges module can set the name of the RecentChanges page; however, if there is no RecentChanges module, there will be no special RecentChanges functionality. e.g.
package UseMod::RecentChanges;
$UseMod::PackageConfiguration{RecentChanges} = T('RecentChanges');
Finally, all these parameters are imported, one after the other. The later a hash is imported, the higher priority it is. The user's configuration is of course the highest, allowing her to override anything else (including the webuser!).
$Parameter{$_} = $derivedConfiguration{$_} foreach (keys %derivedConfiguration);
$Parameter{$_} = $PackageConfiguration{$_} foreach (keys %PackageConfiguration);
$Parameter{$_} = $UserConfiguration{$_} foreach (keys %UserConfiguration);
It's my hope that the user configuration is generated by a friendly helper script as part of the script generation. -- SunirShah