On Sat, 20 Sep 2003, Kate L Pugh wrote:

Can you give a clear statement of the problem you're trying to solve with this? I know we discussed it briefly in the pub, but I'd been drinking, plus the other people on this list weren't all there.

No problem, and while i'm at it i'll include an updated diff file ;)

Problem Statement -----------------

I'm running two OpenGuides sites, Birmingham and Manchester. Because of this I wanted to unify the sites, so that they shared the same code. To do this i made changes to my local copy of the cgi scripts, so that:

1) The config files were located in a folder called 'config', at the same level as the script folder (thereby also removing the config files from the web root)

2) To determine which config file to load i extracted the first portion of the domain name and used that as the filename.

This solution, however, has two main problems:

1) Every time I want to update my OpenGuides installation to the latest version i have to reapply my changes.

2) This is obviously specific to my installation, and would not be suitable in many other cases.

Suggested Solution ------------------

The above led to the suggestion from Kake that I try to come up with a more general solution to the problem, that could (potentially) be included into the offical OpenGuides distribution, thereby solving my problems.

This led to the patch that I posted yesterday, to which I have made some further changes to this morning to simplify the simple case, and have therefore attached to this message.

My patch attempts to solve the problem in the following way:

1) As in my original code change, the config file(s) are moved into a folder called 'config', at the same level as the script folder. I feel that this is essential, due to the database username and password being stored in said file(s).

2) It requires a master config file that is called 'openguides'. This file is of the same style as the normal OpenGuides config file, but currently only has one item, named 'config'. This item is evaluated as a TT2 template, and has access to two lists, 'domain' and 'path', which contain the individual segments of their respective inputs.

For my installation, then, I would use this: config = [% domain.0 %]

This isn't the whole story, however. In order to make the simple case (that of a single OpenGuides site) easier, if:

a) the config item does not exist b) the config item is empty c) the config item contains 'openguides' d) the config item evaluates, through TT, to 'openguides'

Then the master config file itself is used, and no changes other than the location of the file need to be made to existing standard OpenGuides installations. Also, in all the above cases other than d, no TT object is even instantiated, keeping overhead to an absolute minimum.

Suggested Benefits ------------------

1) This makes OpenGuides installations multi-site capable out of the box.

2) It does so without making the simple case of a single-site installation any more complicated.

3) Although patches for the cgi scripts are not included (the changes required are very basic), it should hopefully be obvious that this centralises the knowledge of how to find and load the site config file, removing the need for that code to be in every cgi script.

I humbly submit my patch for examination,

Jody