[Home]WikiCodeSuggestions/Config

UseModWiki | WikiCodeSuggestions | RecentChanges | Preferences

The config system is due for refactoring. Not just my opinion, I have noticed comments elsewhere on this wiki to that effect. I can't remember who said what, but these are some of the current problems

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


R I think that security reasons suggest the default file to be in the same directory as wikimain.pl. I like the idea and support it strongly. -- ElMoro

Hello,

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:


My current design is as follows
  1. Keep wiki.pl so it runs stand-alone, this is very helpful for starting out
  2. Move any true global constants (I think the only one at present is IndentLimit?) up so that they follow $UseConfig
  3. Follow that with the following new code for stand-alone case
    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
  4. Enclose existing default settings in '''sub SetWikiDefaults? { ... }
  5. Move the top of DoWikiRequest up so that it starts off by setting the derived constants ($TempDir? etc) (as in the code in the NoNameWiki? link above)
  6. DoWikiRequest runs a file $DataDir/validation if it exists (allows installers to protect a site against being run with unauthorised config settings)
  7. DoWikiRequest exits unless $UseCGI? - ($UseCGI? could have been set=0 by a config file, or by the validation file to prevent running)
  8. Current DoWikiRequest do /config line removed
  9. Current call to DoWikiRequest removed from foot of file
  10. The standard config file consists of no code at all, but maybe some comments listing what each variable does. Readers are explicitly referrred back to wiki.pl to discover the default settings

Installer Stories

# You should not have to change ...


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


UseModWiki | WikiCodeSuggestions | RecentChanges | Preferences
Edit text of this page | View other revisions | Search MetaWiki
Last edited October 21, 2007 10:57 am by JuanmaMP (diff)
Search: