[pmwiki-users] RFC: PITS 00701 -- WikiFarm confusion

[Patrick R. Michaud]

[Apologies for anyone who receives this message twice -- pmwiki.org's
mail server is having difficulties again and may have dropped my
previous send.  --Pm]

Joachim Durcholz writes:
> However, I still have one question to ask:
> 
> What's the advantages of fields over installing multiple wikis with 
> shared code?
> (Or is it indeed just a terminological problem, and farms are already a 
> shared-code thing?)

Farms are already a shared-code thing.  The first sentence of
PmWiki.WikiFarms reads:

    WikiFarms are a mechanism for running multiple independent 
    wikis on the same web server from a single PmWiki installation.

Perhaps "installation" should say "common code" or something like
that, but essentially PmWiki already does what you say it should do.

> 1) There's one directory for the "wiki engine" and one directory for the 
> "wiki data".

This is how farms and fields currently work.

> 2) The data directory contains the index.php page that starts the 
> machinery. index.php calls the wiki engine with any parameters required 
> to make it find the data directory (ideally, the wiki engine would 
> simply look at the current directory).

This is how PmWiki works now, including using the current directory
for its data directory.

> 3) The engine takes all data from the work directory, falling back to 
> the engine directory whenever the work directory comes up empty. (If 
> this is applied to scripts as well, this can serve to override bits and 
> pieces of the engine with wiki-specific code and configuration.)

This is how PmWiki works now for the wikilib.d/ and skins/ directories.

It's *very* difficult to get PHP to apply this in scripts, since
there's not a "fall back" mechanism that we can use for include 
statements.

> On  a safe_mode-disabled server, this would allow webmasters to install 
> the software, and nail down the configuration so that it "simply works" 
> for their customers.

PmWiki already works this way.  A webmaster can install a copy of
PmWiki in, say, /usr/local/pmwiki, and then customers simply
create directories with index.php files that have

    <?php include_once('/usr/local/pmwiki/pmwiki.php');

The primary reason I don't make reference to /usr/local/pmwiki
in the instructions is that a great many webmasters don't have
the root privileges needed to make this happen.  So then it
just reverts to "wherever PmWiki is installed", which is what
we have now.

> Being part of a web hoster, I can say that such a setup would make 
> PmWiki instantly attractive for us. (Not that it isn't already - but we 
> could then say things like "your WWW site comes with a preinstalled wiki 
> that you can clone if you need multiple wikis", instead of "install and 
> administer your own wikis". We could preinstall recipes that would make 
> sense for our customers. That all would definitely make a difference.)

And yet again: PmWiki is already designed to work in *exactly* 
this manner.

Pm