Much easier would it be as we do it on sf.net with the demo wiki. Or at m=
This explanation is also somewhere at the phpwiki site, and asked multipl=
We have a bunch of small scripts without extensions like 'en', 'de',
'macosx', 'sidebar', 'pear', 'adodb' and so on.
Each of these files has the php handler attached in the .htaccess file,
and overrides some config values, loads the phpwiki index.php, overrides
some other variables, and loads lib/main.php.
<?php // -*-php-*-
// CONSTANTS as default wiki overrides before:
// other VARIABLE overrides here:
This way you keep the site configuration in config.ini, and some special
constants, like VIRTUAL_PATH, WIKI_NAME, DEFAULT_PGSRC, $LANG, CHARSET,
and so on in the various loaders. See PrettyWiki.
And don't really like Matthews idea.
Different lib is impossible om the same phpwiki, please rename special
different config files are also easy, but generally not needed.
see the content of index.php. These four lines could go into your start
script if you really need different config files.
But you have to declare PHPWIKI_DIR and DATA_PATH then, because you
started phpwiki out of the phpwiki directory.
> On Sat, May 22, 2004 at 10:18:59AM +1200, Jim Cheetham wrote:
>> How difficult would it be to virtualise the entire wiki? I'd like to b=
>> able to install the Debian package once, probably into
>> /usr/share/phpwiki/ ... and then in various VirtualHosts be able to
>> declare a (uniquely-named) wiki, that would be able to pick a differen=
>> config file (and possibly a different 'additional lib' for plugins) ..=
> As it stands, it wouldn't be particularly simple, because PHPWiki does
> everything from it's index file, which is hardcoded to look for it's
> config file in one place. We need to tell index.php to get it's config
> different places depending on which virtual instance invoked it for thi=
> particular run.
> What I have just recently done for another project is to create multipl=
> configuration instances by indexing a config file by a unique substring=
> the URL. So, if you've got two PHPWiki sites http://www.site.com/wiki =
> http://www.site.com/otherwiki, your config sections would be linked to
> '/wiki' and '/otherwiki'. Similarly, If they're on different virtual
> entirely, you can have your sections as 'site1.com' and 'site2.com' if
> they're the unique substrings.
> This is cute because it requires nothing more than to set up another
> in your config file for the new vhost and add an alias. It's a PITA fo=
> PHPWiki because it would almost certainly mean a new config file to han=
> the substring =3D> config file mapping, as you wouldn't want multiple
> configs in the one file (it'd be a little long and confusing).
> Another method, if you wanted it, that would work in PHPWiki more or le=
> as-is, would be to use the other method I devised for the above project
> (which I didn't use as the substring method was more appropriate in tha=
> case). Create a constant, perhaps called __CONFIGURED, that will be
> true once all of the appropriate config statements have been processed.
> Then, tell index.php not to call IniConfig() (or tell IniConfig() not t=
> anything) if __CONFIGURED is defined.
> How does this help? Because you put something like the following in yo=
> apache.conf for each of the virtualised PHPWiki instances:
> php_value auto_prepend_file /some/config/file.php
> Where /some/config/file.php is unique for each instance, and contains
> much the following code:
> require_once '/usr/share/phpwiki/lib/IniConfig.php';
> define('__CONFIGURED', true);
> Again, where /some/config/file.ini is unique to that virtual instance o=
> PHPWiki and filled with lovely local-specific config options.
> You then point each virtual instance of PHPWiki at /usr/share/phpwiki f=
> it's code, index.php runs for everyone but skips the default config for
> virtual instances because __CONFIGURED is defined, and IniConfig() has
> previously run with your per-instance config file.
> If you're interested in using this method (which I think may be the bet=
> option for PHPWiki), I'm happy to patch index.php in Debian to support
> as it doesn't break anything in the default case (single instance, conf=