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 ;)
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.
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',
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
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,