On Thu, Aug 13, 2009 at 5:16 AM, Dmitriy Sintsov<questpc(a)rambler.ru> wrote:
MW_INSTALL_PATH is great, but it can cause the
inclusion from the
another MediaWiki installation on the same server (once I've had such
error on v1.14 farm and v1.15 "alone for testing purposes") .
What about going down to path looking for dirs containing file
LocalSettings.php ? Then it will be a $IP.
That doesn't work unless the thing that's doing the looking starts off
in some subdirectory of the install path. For, e.g., a checkout of
trunk, this isn't the case. It's also a huge amount of code
duplication in the case of extensions that need to include something
like maintenance/commandLine.php.
On Thu, Aug 13, 2009 at 1:06 PM, Brion Vibber<brion(a)wikimedia.org> wrote:
Yes, it's a pain in the ass. ;)
It's a problem that may or may not have a good solution. If nobody
can come up with a good solution, then I guess there's no good
solution. But symlinking stuff works just fine for almost every
extension out there right now, and is convenient if you have a single
checkout of trunk (which is necessary if you want to be able to change
both phase3 and extensions without multiple commits). Standalone
scripts are the only problem I can think of that would ever arise. I
don't think it's necessary to just say the setup is uniformly a bad
idea and everyone who does it should fix their setup rather than
asking for reasonable accommodation.
Note also that many extensions have user interface
components including
JavaScript, CSS, and image files -- we need a predictable path to reach
them, and that's the extensions folder.
That works fine with symlinks.
Standalone scripts should be loading up
includes/WebStart.php or
maintenance/commandLine.inc and not attempting to find LocalSettings.php
themselves.
In any case they need to be able to find and reach that setup info,
which is what a stable directory tree provides.
Yes, that's the puzzle. I guess extensions could special-case the
trunk checkout case by checking ../../phase3/ if ../../ fails, or (for
maintenance scripts) maybe use some environment variable. But that
would be an awful lot of code duplication. The problem is you can't
use any sort of shared code here, since you have no idea where the
path is to begin with . . . hmm.
Okay, I know. Someone with a trunk checkout could duplicate the
content of phase3/ in the root of their checkout in the form of
symlinks pointing to the right place. The only naming conflict is, of
course, extensions/, which is probably fine. So that should work okay
from all perspectives. Although it's slightly evil. :D