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