[Pmwiki-users] one installation, multiple wikis

[Crisses]

I've seen the REQUEST_URI solution and John Feezel's solution which is 
based on pointing symbolic links to a base pmwiki installation.  I'm 
looking for something with the least amount of server overhead (the 
symbolic links might work very well for that.  However I don't like the 
method that adds to what PmWiki needs to process on the server) that is 
preferably as uncomplicated as possible so that it can be well 
documented and possibly even automated.


I had to change webhosts so now I've set up my 2 wikis in their own 
directories on a relatively slow server -- my kinhost.org wiki and my 
(auto)biography wiki bring the total of wikis installed on the same 
server to at least 4...and the poor thing is only a 233mhz machine ;) . 
  I want it to be easier to upgrade the wikis, and to take up less real 
estate on the hard drive, so I'm trying to bring a solution to the 
person who is hosting my sites.  I also know another person who wants 
to do similar on their machines.

What I'm using in both installs is a wiki wrapper to change the name of 
the URL that appears in the browser i.e. "wiki" is now defined as a php 
file, and is placed in the root of the url in question and it's all 
working very very nicely (that solution is on 
http://www.pmichaud.com/wiki/PmWiki/ChangePmWikiURL).  Because the 
wrapper calls pmwiki directly, the pmwiki install can easily be moved 
below the publicly accessible web folders.  I am wondering if there's a 
way to alter this so that multiple installations share wiki 
installation in a method that's easier to maintain and explain to new 
users than symbolic links.  Perhaps by defining separate folders for 
wiki.d documentation and separate config files via the wrapper script.

Are these files & folders defined by pmwiki variables or are they flat 
calls to certain files?  can a local folder contain, for example, 
"ofobscurityconfig.php" and "kinhostconfig.php" and the wrapper for the 
respective wikis contain overrides for such things such as :

<?php

// deluxe "wiki" wrapper -- be sure to change .htaccess or Apache 
configs to allow this file to be php
// by adding:
// <Files wiki>
//    SetHandler application/x-httpd-php
// </Files>
// and name this file "wiki" and place it in the root of your web 
directory


$LOCAL_CONFIG = "/dir/to/my_local_config.php"; // overrides default 
filename of "config.php"
$WIKI_DATA_DIR = "/dir/to/my_wiki.d_replacement"; // allows keeping the 
wiki.d directory somewhere else, or renaming it per-site

chdir("/path/to/pmwikidir");
include_once "pmwiki.php";
?>

And thus each wrapper file would override the necessary variables for 
that particular wiki site without needing multiple installations of the 
basic pmwiki package....

One great thing about this is that we have been thinking we can get 
pmwiki into the debian tree...but we need to standardize certain 
aspects of installation and upgrading to get it there.  This fun stuff 
allows a webhost to have people run it on a server and they can place 
their local config files in their user accounts, and have access to 
backing up their own wiki.d directory (or even rename it if need be).  
Upgrades to the basic installation cover the whole site, just like with 
the other suggestions...but without people stepping on each others' 
local customizations.

Is this feasable?  Are there already pmwiki variables set up for these 
things?  If not, how difficult would it be to modify the wiki for 
something like this?

Crisses
-- 
Take into consideration that science is not infallible and that it once 
was based upon beliefs not any better proven than our own theories on 
reality, until someone figured out ways to test the theories...even 
then, the best they can do to prove one theory is to prove that no 
other theory explains the phenomenon in question *better* than it.  The 
only scientific truth is that which has not been proven false.

On Jan 23, 2004, at 11:01 AM, Patrick R. Michaud wrote:

> Niall-
>
> The solution you described below is exactly what I would've 
> recommended. :-)
>
> Pm
>
>> This script will check the REQUEST_URI to make sure the group and
>> hostname match.  If they don't, it will reformat the request with the
>> proper hostname and return a 301 w/ the corrected URL.
>>
>> We want something that's easy to maintain as we add more sites and
>> allows pre-existing incorrect hostname URLs will still work.  With
>> this approach, we only have to add one line to this "group ->
>> hostname" script for each new site/group we add, and add an
>> include_once() line to each customized group script.
>>
>> So...  The reason I'm spamming everyone is to see if someone has
>> already solved this problem and/or has a better solution/idea than
>> I'm planning to implement.