On Nov 30, 2004, at 10:50 PM, Jonah Bossewitch wrote:
need to change index.php, this is what LocalSettings.php is
for. (Nor do we need more than one of it, as site-specific setup logic
happens under it and its includes.)
Maybe I am confused, but as I understood it, the wikipedia site itself
is running with an alternative configuration, described here:
and using this additional configuration
Yes, that's a description of how we use MediaWiki with a single copy of
the source to run several hundred wikis with varying configurations.
and presumably, a modified index.php
or LocalSettings that initializes and
uses the SiteConfiguration object.
Yes! That's the purpose of LocalSettings.php; to load all
The 1.3.8 download does not do
ordinarily use of the SiteConfiguration object.
The common case is a single installation on a hosted account where
there is limited control and fancy stuff won't work. Thus, the default
installation is the simple, reliable in-place system.
For those of us doing big multi-wiki installations, we can relatively
easily move the files, set up a global include_path, and whip up a
multi-configuration LocalSettings.php file to suit our needs. The
SiteConfiguration object is a multi-configuration helper that Tim came
up with to make this easier, but it's just one way to do it.
As a very typical use case, imagine trying to power
two (or more)
mediawiki instances on the same server that are branded completely
differently. One way to model this is for each of them to have their
own skin, which can be worked on separately and independently by
webdesign specialists. Creating a custom phptal skin requires
extending the SkinPHPTal class.
You would probably do this with separate subclassed skins for each
"brand", rather than hacking the base class.
You wouldn't need even this if customizing the style sheets and
messages is sufficient; this can be done purely from within the wiki
interface (MediaWiki:Monobook.css, MediaWiki:MySkin.css, etc), or you
can hack up a separate stylesheets directory and use the appropriate
one for each wiki without changing any of the base source.
If you are managing custom code for two different
they really should be in their own versioned repositories, not
If you have set yourself the requirement of having separate
version-controlled sets of source, then by definition you're going to
have some difficulty running them both from a common set of source. I
don't think this should be necessary, however.
Beyond that, you may want to extend different
(special pages, extensions, etc) differently for each project (not in
a server-wide way). So some special pages may exist on wiki A, but
not on wiki B, but you would still like for wiki A and B to be running
off the same set of source.
Extensions are to be loaded from LocalSettings.php, so you can load
I guess it
just seems a bit weird to have people tell us why they
can't use our software to run multiple sites off one set of source
when running multiple sites off one set of source is exactly what we
do day after day.
Is this really such a weird requirement?
It's not weird at all; it's exactly what we do with it after all.
What's weird is when we get told that we can't possibly be doing what
we're doing because it's impossible.
I am fairly sure there is no easy
way to manage the collaborative development of multiple custom wikis
without giving each of them their own "private" space. The challenge
is doing so w/out having to replicate the core code for each instance.
I'm not sure what that means, so I can't really comment on it.
-- brion vibber (brion @ pobox.com