On 16/10/12 02:42, Axel Thimm wrote:
Hi,
What patch are you using? How is it configured?
http://pkgs.fedoraproject.org/cgit/mediawiki.git/tree/mediawiki-1.16.2-comm…
It uses $IP as the code path and $DIR as the data path.
We should have used $IP explicitely in a few places instead of relative
paths.
Do note that
- if ( file_exists(
'config/LocalSettings.php' ) ) {
+ if ( file_exists( $DIR . 'config/LocalSettings.php' ) ) {
is wrong ($DIR
doesn't contain a trailing slash)
I've examined the current other solutions of doing
so (e.g. as
outlined on
http://www.mediawiki.org/wiki/Manual:Wiki_family but none
really provides a single source-multiple data solution w/ arbitrary
install location for the instances and no special handling in
LocalSettings.php.
You need some config switching somewhere. Perhaps the LocalSettings.php
from MediaWiki POV could simply select from different subordinate
LocalSettings.php
The patch worked by splitting the paths based on the current working
directory (= instance path) vs a hard coded path for the mediawiki
code).
Basing it on variables set in .htaccess/server config may be the way to go.
You could almost set $IP that way defining MW_INSTALL_PATH on php.ini
Ideally we'd modify mediawiki in Fedora/RHEL to
allow for concurrent installs of different mediawiki versions
May I ask why would you want this?
Ideally, you shouldn't ever need anything other than the latest version.
In a pakaged distribution an upgrade of mediawiki w/o keeping the
previous version would imply automatically running the mathing
upgrade.php scripts on each instance.
First of all, I'd prefer if this is done by the user/admin of the
instance. And next it may be that on a hosting wiki farm different
users will want to upgrade at different times.
But that is more a packaging issue that can be easily solved with the
current upstream code.
IMHO upgrading the package should automatically run update.php on all
the instances linked to it (which in turn needs some sort of central
registry, how are you handling that?).
o allow simple imports/migration of unpackaged
mediawiki sites w/o
changes to LocalSettings.php
The custom config at the user LocalSettings.php would need to reflect
somewhere in your setup.
The user's LocalSettings.php doesn't need to be patched if the main
code is to split the $IP variable (as done in the patch). The only
thing left is how to setup the code path. The patch mentioned above
uses a dirty hardwired path. A cleaner solution would allow to specify
a different code path from the current working directory (but default
to the current working directory to keep backwards compatible).
I see.
Would it be acceptable to mediawiki devs to split the
use of $IP
between code and data instances? In that case we should try to patch
upstream into 1.20 this change, so all distributrions could simply use
a central code/multiple data farm setup.
You mean as used for locating the files and as basis for the
$wg*Directory variables? Seems doable easily. Any suggestion for the
name of the "data $IP" ?
I used $DIR which is as bad as a name could had been, so I'll admit to
zero creativity in name giving. :/
Something that reflects "instance", "data", (local)
"config" etc.
We could use MW_DATA_PATH for the define. Not sure about the variable.