[Pmwiki-users] one installation, multiple wikis
Fri Mar 19 08:31:54 CST 2004
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 :
// 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
// and name this file "wiki" and place it in the root of your web
$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
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'
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?
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:
> The solution you described below is exactly what I would've
> recommended. :-)
>> 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.
More information about the pmwiki-users