I have been following this MultiHosting thread, as well as the hooks and
filters thread with great interest.
I think that one of the most crucial aspects of successfully integrating
open source solutions is treating the core distribution as "read only".
Mediawiki 1.3x makes it very difficult to adhere to this principle - it is
too tempting, (often irresistible ;-)), to modify the core distribution.
Performing in-place customizations makes upgrades very very difficult, and
worse, makes people's problem idiosyncratic (ruining most hope for support
from the community, or return contributions).
I think one of the primary design goals 1.4 and up should be designing
software that does not require, nor encourage, the direct modification of
the core distribution.
Pluggable auth, the proposed, the extensions and special file handling, and
especially the hooks and filters proposal are steps in the right direction.
When it came to multiple hosting, I had a choice of following the mediawiki
setup, or the helpful suggestion of Mark Constable (Thanks!). While the
mediawiki setup might ultimately provide ttw instance creation, it also
presents its own shortcomings. Mark's suggestion, with a little
interpolation, allows for a great deal of flexibility. It allows for the
creation of lightweight wiki instances that run off a common software
installation. Likewise, its also makes it easier to manage the
customizations on the file system using standard version control tools, as
well as manage code from across development/staging/production environments.
I am not talking about treating the wiki as a cms or even development
platform, but if you want to do extensive customizations of the skins, or
involve more than one developer on a wiki project, this kind of control is
essential.
Here is the setup that I am currently using:
$SOFTWARE_HOME/<standard untarred mediawiki>
$INSTANCE_HOME/InstanceSettings.php
$INSTANCE_HOME/bootstrap.php
$INSTANCE_HOME/images/
$INSTANCE_HOME/includes/SkinMyCustomSkin.php
$INSTANCE_HOME/index.php
$INSTANCE_HOME/redirect.php
$INSTANCE_HOME/stylesheets/myCustomSkin
$INSTANCE_HOME/templates/
where index.php is:
-------------------
<?php
error_log(var_export($_REQUEST, true));
$wgRequestTime = microtime();
unset( $IP );
ini_set( "allow_url_fopen", 0 ); # For security...
if(!file_exists("./InstanceSettings.php")) {
die( "You need to configure your sandbox before this wiki can work" );
}
define( "MEDIAWIKI", true );
require_once("./bootstrap.php");
require_once( "$SOFTWARE_HOME/LocalSettings.php" );
require_once( "./InstanceSettings.php" );
# inlcude our skin, so that we don't have to modify core code
require_once("SkinCCNMTL.php");
# mediawiki.php is the same as the original index.php, with the top few
lines c
ommented out
require 'mediawiki.php';
?>
redirect.php is a straight copy of the one in software_home (it needs to be
a copy, not a link, or the ./LocalSettings.php include will happen inside
the software_home directory, not the instance_home directory.
bootstrap.php is
-------------------
<?php
#
# this file definesthe environemnt specific paths and resources, per sandbox
$IP = $SOFTWARE_HOME = "/usr/local/share/sandboxes/common/mediawiki-src";
$INSTANCE_HOME = "/usr/local/share/sandboxes/jonah/uwpwiki";
$INSTANCE_URL_BASE = "http://wiki.columbia.edu:8080";
$INSTANCE_URL_PATH = "/sb/jonah/mediawiki";
ini_set( "include_path",
".:$INSTANCE_HOME:$INSTANCE_HOME/includes:$INSTANCE_HO
ME/templates:$IP:$IP/includes:$IP/languages" );
?>
The only modification I needed to make in the core distro was copying
index.php -> mediawiki.php and commenting out the first ~15 lines (up until
requiring includes/Setup.php).
This index.php combined with the include_path allows me to set up sandbox
specific settings, instance specific settings, as well as server wide,
global settings (in the LocalSettings and DefaultSettings).
If the core mediawiki introduced a similar construct, I wouldn't even need
to modify the original index.php inside of software home.
I think this kind of structure would encourage people to use more OO
techniques such as extension (w/in your own instance's include path, which
is picked up before the software home one), and in general, keep folks away
from the core distribution.
Thanks for all your help.
Jonah