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

[Joachim Durchholz]

Patrick R. Michaud schrieb:
> 
> 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.

   if (is_readable ($local_dir . '/' . $file)) {
     include ($local_dir . '/' . $file);
   } else {
     include ($fallback_dir . '/' . $file);
   }

This code works even if it is inside a function like this:

function include_file ($file) {
   if (is_readable ($local_dir . '/' . $file)) {
     include ($local_dir . '/' . $file);
   } else {
     include ($fallback_dir . '/' . $file);
   }
}

Well, sort of: variables assigned to within the included files will be 
local to include_file(). (Workaround: add a "global" directive.)
Function and class definitions inside the included file will be exported 
into the global scope though.

(Just tested with PHP 4.4.4.)

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

How would I make sure that the scripts/ directory is taken from 
/usr/local/pmwiki?
chdir() won't work, PmWiki would then take the local/ directory (and 
config.php) from the central installation, too.

>> 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.

I haven't found recipes to do that.

Well, maybe I overlooked the recipe because it wasn't clearly marked as 
"separates generic PmWiki stuff from stuff that applies to a specific 
slave wiki".
The slogan "separate code from data" doesn't adequately describe what I 
had in mind; it ignores that some components of a PmWiki installation 
could be partly local, partly global: recipes, skins, configuration, 
pages. It's more like a fallback mechanism.

Regards,
Jo