Re: [Wikitech-l] More fun and games with file position relative code
2009/8/14 Brion Vibber br...@wikimedia.org: On my production wiki I have phase3/ checked out in /var/www/w, and some extensions individually checked out in subdirectories of /var/www/w/extensions. When I do svn up in /var/www/w, that doesn't update the other repositories in extensions/; I have to do svn up . extensions/* instead. Does commit work differently, or am I misunderstanding? svn up works just fine for this too in my experience. Perhaps your 'extensions' dir isn't SVN-managed for some reason, or something? The reason this is happening is that Brion did rm -rf extensions/ svn co svn+ssh://svn.wikimedia.org/svnroot/trunk/mediawiki/extensions whereas Aryeh (and I too, FTM) did cd extensions/ svn co svn+ssh://svn.wikimedia.org/svnroot/trunk/mediawiki/extensions/Foo svn co svn+ssh://svn.wikimedia.org/svnroot/trunk/mediawiki/extensions/Bar In the latter case, you don't get all extensions, but svn commands on phase3 don't affect extensions. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] More fun and games with file position relative code
Aryeh Gregor wrote: On Thu, Aug 13, 2009 at 3:24 PM, Ilmari Karonennos...@vyznev.net wrote: You don't need symlinks for that, a simple svn switch works just fine. Could you explain in more detail? I don't get how that would work. From memory (don't feel like doing a new checkout over this crappy wlan just to test it right now): svn co svn+ssh://svn.wikimedia.org/svnroot/trunk/mediawiki/phase3 foo svn switch svn+ssh://svn.wikimedia.org/svnroot/trunk/mediawiki/extensions foo/extensions But you're right, that doesn't really work if you only want a few extensions, not all of them. Although, IME, for a development copy one usually does want all the extensions, if any. -- Ilmari Karonen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] More fun and games with file position relative code
On 13/08/2009, at 10:16 AM, Dmitriy Sintsov wrote: I wish MediaWiki had farm-friendly LocalSettings.php (loading different set of $wg* variables according to host name), which would not require symlinks (not available in Windows). I do use Linux for hosting, but sometimes I have to debug in Windows. SO I make my own LocalSettings.php. Also, I think it would be great if these global static variables would be placed into static classess according to their purposes (usually there are the sets of variables which are designated to some aspect of wiki functioning). There's plenty of stuff for this — it's what we use on Wikimedia. Essentially, you can construct the database name by looking at the request path and host and so on ($_REQUEST array), and then use the SiteConfiguration object. -- Andrew Garrett agarr...@wikimedia.org http://werdn.us/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] More fun and games with file position relative code
On Thu, Aug 13, 2009 at 05:16, Dmitriy Sintsovques...@rambler.ru wrote: I wish MediaWiki had farm-friendly LocalSettings.php (loading different set of $wg* variables according to host name), which would not require symlinks (not available in Windows). Actually, symlinks are available in Windows as the NTFS junction feature. Here's a great little GUI utility for creating them (I don't have the Windows command line syntax memorized): http://www.rekenwonder.com/linkmagic.htm On XP and below, you'll want to avoid deleting the symlinks you create directly in Windows Explorer, as this will delete the target folder as well. Unlink before deletion. On Vista and up, this is handled correctly -- only the symlink is deleted. I've never actually run into this myself, but it's good to give the warning. Regards, Leons Petrazickis http://lpetr.org/blog/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] More fun and games with file position relative code
* Leons Petrazickis leons.petrazic...@gmail.com [Thu, 13 Aug 2009 10:35:51 -0400]: On Thu, Aug 13, 2009 at 05:16, Dmitriy Sintsovques...@rambler.ru wrote: I wish MediaWiki had farm-friendly LocalSettings.php (loading different set of $wg* variables according to host name), which would not require symlinks (not available in Windows). Actually, symlinks are available in Windows as the NTFS junction feature. Here's a great little GUI utility for creating them (I don't have the Windows command line syntax memorized): http://www.rekenwonder.com/linkmagic.htm On XP and below, you'll want to avoid deleting the symlinks you create directly in Windows Explorer, as this will delete the target folder as well. Unlink before deletion. On Vista and up, this is handled correctly -- only the symlink is deleted. I've never actually run into this myself, but it's good to give the warning. Regards, Leons Petrazickis http://lpetr.org/blog/ Thanks, but the symlinks still are the aliens to Windows - long time ago I've seen these created by some (Sysinternals ?) tools, I remember they were not visually highlighted and not provided with actual target in cmd.exe and Explorer, in contrary to Linux bash. Anyway, I run my farm without symlinks at all, by using modified version of LocalSettings.php Speaking of $IP, if you'll get a value of dirname( __FILE__ ), then split it to parts separated with '/' and check the dirs down for existance of LocalSettings.php, you should reliably get $IP in such way from any depth of inclusion, I think. Dmitriy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] More fun and games with file position relative code
On 8/12/09 6:43 PM, Aryeh Gregor wrote: On Wed, Aug 12, 2009 at 5:03 PM, Brion Vibberbr...@wikimedia.org wrote: Your setup is incorrect: the extensions folder *always* goes inside the MediaWiki root dir. Always. I don't do this on my development wiki. I use a checkout of trunk, so extensions/ is inside phase3/../. Are there any significant problems with us supporting extensions/ being in an arbitrary location, Yes, it's a pain in the ass. ;) 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. as long as phase3/extensions/ reliably points to it both on the web and filesystem level? Is there really no other reliable way to do standalone PHP scripts in extensions than require_once ../../LocalSettings.php? 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. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] More fun and games with file position relative code
On Thu, Aug 13, 2009 at 5:16 AM, Dmitriy Sintsovques...@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 Vibberbr...@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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] More fun and games with file position relative code
That's the reason why I always symlink extensions/ to my common extensions folder. /path/to/common/extensions/ /path/to/mywiki/* /path/to/mywiki/extensions -symlink- /path/to/common/extensions/ /path/to/anotherwiki/* /path/to/anotherwiki/extensions -symlink- /path/to/common/extensions/ It works perfectly fine for extension's interface components, it's great for checking out the entire svn extensions but still having separate wiki installations, while avoiding eating up disk space unnecessarily. It's perfectly valid, but the maintenance script issue is still there. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] Brion Vibber wrote: On 8/12/09 6:43 PM, Aryeh Gregor wrote: On Wed, Aug 12, 2009 at 5:03 PM, Brion Vibberbr...@wikimedia.org wrote: Your setup is incorrect: the extensions folder *always* goes inside the MediaWiki root dir. Always. I don't do this on my development wiki. I use a checkout of trunk, so extensions/ is inside phase3/../. Are there any significant problems with us supporting extensions/ being in an arbitrary location, Yes, it's a pain in the ass. ;) 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. as long as phase3/extensions/ reliably points to it both on the web and filesystem level? Is there really no other reliable way to do standalone PHP scripts in extensions than require_once ../../LocalSettings.php? 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. -- brion -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] More fun and games with file position relative code
On 8/13/09 10:55 AM, Aryeh Gregor wrote: On Thu, Aug 13, 2009 at 1:06 PM, Brion Vibberbr...@wikimedia.org wrote: 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, Why? Just put your extensions in the extensions folder where they belong. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] More fun and games with file position relative code
Aryeh Gregor wrote: 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). You don't need symlinks for that, a simple svn switch works just fine. -- Ilmari Karonen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] More fun and games with file position relative code
On Thu, Aug 13, 2009 at 4:17 PM, Bryan Tong Minhbryan.tongm...@gmail.com wrote: On Thu, Aug 13, 2009 at 3:43 AM, Aryeh Gregorsimetrical+wikil...@gmail.com wrote: On Wed, Aug 12, 2009 at 5:03 PM, Brion Vibberbr...@wikimedia.org wrote: Your setup is incorrect: the extensions folder *always* goes inside the MediaWiki root dir. Always. I don't do this on my development wiki. I use a checkout of trunk, so extensions/ is inside phase3/../. Are there any significant problems with us supporting extensions/ being in an arbitrary location, as long as phase3/extensions/ reliably points to it both on the web and filesystem level? Is there really no other reliable way to do standalone PHP scripts in extensions than require_once ../../LocalSettings.php? We could add a global $wgExtensionMaintenanceScripts['scriptName'] = 'ExtensionMaintenanceClass::doSomeMaintenance'; and add a maintenance script performExtensionMaintenance.php scriptName which calls the maintenance function of the extension. The file will then get autoloaded by the autoloader. Bryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l See $wgMaintenanceScripts as of the maintenance-work branch merge. It would be pretty trivial to write a script to execute maintenance scripts located elsewhere. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] More fun and games with file position relative code
On Thu, Aug 13, 2009 at 2:25 PM, Brion Vibberbr...@wikimedia.org wrote: Why? Just put your extensions in the extensions folder where they belong. Then what do I do if I want to commit to both phase3/ and extensions/ at once? Or even just check both of them out at once? Am I supposed to maintain several repositories and update them separately? On Thu, Aug 13, 2009 at 3:24 PM, Ilmari Karonennos...@vyznev.net wrote: You don't need symlinks for that, a simple svn switch works just fine. Could you explain in more detail? I don't get how that would work. On Thu, Aug 13, 2009 at 4:17 PM, Bryan Tong Minhbryan.tongm...@gmail.com wrote: We could add a global $wgExtensionMaintenanceScripts['scriptName'] = 'ExtensionMaintenanceClass::doSomeMaintenance'; and add a maintenance script performExtensionMaintenance.php scriptName which calls the maintenance function of the extension. The file will then get autoloaded by the autoloader. That would work, but it's probably not worth the burden on normal people who have their extensions really in extensions/. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] More fun and games with file position relative code
On 8/13/09 3:32 PM, Aryeh Gregor wrote: On Thu, Aug 13, 2009 at 2:25 PM, Brion Vibberbr...@wikimedia.org wrote: Why? Just put your extensions in the extensions folder where they belong. Then what do I do if I want to commit to both phase3/ and extensions/ at once? svn commit Or even just check both of them out at once? svn co svn+ssh://svn.wikimedia.org/svnroot/trunk/mediawiki/phase3 cd phase3 rm -rf extensions svn co svn+ssh://svn.wikimedia.org/svnroot/trunk/mediawiki/extensions I've been doing this for years with no problems. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] More fun and games with file position relative code
On Thu, Aug 13, 2009 at 7:40 PM, Brion Vibberbr...@wikimedia.org wrote: On 8/13/09 3:32 PM, Aryeh Gregor wrote: Then what do I do if I want to commit to both phase3/ and extensions/ at once? svn commit This works in SVN if you have two checkouts nested within each other? Don't commands like commit and diff only affect the current repository? On my production wiki I have phase3/ checked out in /var/www/w, and some extensions individually checked out in subdirectories of /var/www/w/extensions. When I do svn up in /var/www/w, that doesn't update the other repositories in extensions/; I have to do svn up . extensions/* instead. Does commit work differently, or am I misunderstanding? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] More fun and games with file position relative code
On 8/13/09 4:51 PM, Aryeh Gregor wrote: On Thu, Aug 13, 2009 at 7:40 PM, Brion Vibberbr...@wikimedia.org wrote: On 8/13/09 3:32 PM, Aryeh Gregor wrote: Then what do I do if I want to commit to both phase3/ and extensions/ at once? svn commit This works in SVN if you have two checkouts nested within each other? Yup. Don't commands like commit and diff only affect the current repository? In theory, however it doesn't seem to care if you've monkeyed about with the directory structure of things that *are* in the same repository. ;) On my production wiki I have phase3/ checked out in /var/www/w, and some extensions individually checked out in subdirectories of /var/www/w/extensions. When I do svn up in /var/www/w, that doesn't update the other repositories in extensions/; I have to do svn up . extensions/* instead. Does commit work differently, or am I misunderstanding? svn up works just fine for this too in my experience. Perhaps your 'extensions' dir isn't SVN-managed for some reason, or something? -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] More fun and games with file position relative code
On Thu, Aug 13, 2009 at 9:12 PM, Brion Vibberbr...@wikimedia.org wrote: svn up works just fine for this too in my experience. Perhaps your 'extensions' dir isn't SVN-managed for some reason, or something? It has a .svn directory in it . . . of course, I use git for development anyway. It's worked so far, so I don't really care too much. If I really need to run a maintenance script in an extension, I'm sure I'll be able to get it to work easily enough. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] More fun and games with file position relative code
So. I checked out a copy of phase3 and extensions to start working on
investigating the feasibility of a comprehensive parser regression test. After
getting the working copy downloaded, I do what I usually do - blow away the
extensions directory stub that comes with phase3 and soft link the downloaded
copy of extensions in its place. I then began familiarizing myself with
DumpHTML by starting it up in a debugger. Guess what happened.
If fell over. Why? Because DumpHTML is yet another software module that
computes the value $IP. So what? Well, DumpHTML.php is located in
../extensions/DumpHTML. At line 57-59 it executes:
$IP = getenv( 'MW_INSTALL_PATH' );
if ( $IP === false ) {
$IP = dirname(__FILE__).'/../..';
}
This works on a deployed version of MW, since the extensions directory is
embedded in /phase3. But, in a development version, where /extensions is a
separate subdirectory, ./../.. does not get you to phase3, it gets you to MW
root. So, when you execute the next line:
require_once( $IP./maintenance/commandLine.inc );
DumpHTML fails.
Of course, since I am going to change DumpHTML anyway, I can move it to
/phase3/maintenance and change the '/../..' to '/..' and get on with it. But,
for someone attempting to fix bugs in DumpHTML, the code that uses a knowledge
of where DumpHTML.php is in the distribution tree is an issue.
Dan
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] More fun and games with file position relative code
On Wed, Aug 12, 2009 at 4:39 PM, dan nessettdness...@yahoo.com wrote:
So. I checked out a copy of phase3 and extensions to start working on
investigating the feasibility of a comprehensive parser regression test.
After getting the working copy downloaded, I do what I usually do - blow away
the extensions directory stub that comes with phase3 and soft link the
downloaded copy of extensions in its place. I then began familiarizing myself
with DumpHTML by starting it up in a debugger. Guess what happened.
If fell over. Why? Because DumpHTML is yet another software module that
computes the value $IP. So what? Well, DumpHTML.php is located in
../extensions/DumpHTML. At line 57-59 it executes:
$IP = getenv( 'MW_INSTALL_PATH' );
if ( $IP === false ) {
$IP = dirname(__FILE__).'/../..';
}
This works on a deployed version of MW, since the extensions directory is
embedded in /phase3. But, in a development version, where /extensions is a
separate subdirectory, ./../.. does not get you to phase3, it gets you to
MW root. So, when you execute the next line:
require_once( $IP./maintenance/commandLine.inc );
DumpHTML fails.
Of course, since I am going to change DumpHTML anyway, I can move it to
/phase3/maintenance and change the '/../..' to '/..' and get on with it. But,
for someone attempting to fix bugs in DumpHTML, the code that uses a
knowledge of where DumpHTML.php is in the distribution tree is an issue.
Dan
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
DumpHTML will not be moved back to maintenance in the repo, it was
already removed from maintenance and made into an extension. Issues
with it as an extension should be fixed, but it should not be encouraged
to go back into core.
Also, on a meta notecan you possibly confine all of your testing comments
to a single thread? We don't need a new thread for each problem you find :)
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] More fun and games with file position relative code
Chad innocentkil...@gmail.com wrote: DumpHTML will not be moved back to maintenance in the repo, it was already removed from maintenance and made into an extension. Issues with it as an extension should be fixed, but it should not be encouraged to go back into core. What I meant was I can move the code in DumpHTML as CPRT to maintanence in my working copy and work on it there. Whether this code is simply a MacGyver test or something else is completely up in the air. Also, on a meta notecan you possibly confine all of your testing comments to a single thread? We don't need a new thread for each problem you find :) My apologies. Dan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] More fun and games with file position relative code
On 8/12/09 1:39 PM, dan nessett wrote: This works on a deployed version of MW, since the extensions directory is embedded in /phase3. But, in a development version, where /extensions is a separate subdirectory Your setup is incorrect: the extensions folder *always* goes inside the MediaWiki root dir. Always. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] More fun and games with file position relative code
On Wed, Aug 12, 2009 at 6:04 PM, dan nessettdness...@yahoo.com wrote: --- On Wed, 8/12/09, Brion Vibber br...@wikimedia.org wrote: Your setup is incorrect: the extensions folder *always* goes inside the MediaWiki root dir. Always. Sorry, my inexperience with Subversion led me in the wrong direction. I didn't realize I could check out phase3 then point Subversion to the extensions directory in phase3 to check out extensions. I thought Subversion would get confused, but I just tried it and it worked :-). At least Subversion performed the checkout. I haven't tried doing an update. I just (case sensitively) searched the extensions directory for the string $IP = and found 32 files that compute $IP on their own. How about creating a standard bit of code that extensions and other modules can copy and use to figure out MW root. For example, it is very unlikely that the name of the first level directory (i.e., phase3) will change. The code can call dirname( __FILE__ ) and then search from the end of the pathname until it finds phase3. It then knows that the prefix is MW root. Dan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Not true. People can name phase3 whatever they want. I have phase3, wmf-deployment, new-install, maintenance-work and w as wiki roots. You can name it anything you want, so don't rely on the 'phase3' name at all. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] More fun and games with file position relative code
dan nessett wrote:
--- On Wed, 8/12/09, Brion Vibber br...@wikimedia.org wrote:
Your setup is incorrect: the extensions folder *always*
goes inside the
MediaWiki root dir. Always.
Sorry, my inexperience with Subversion led me in the wrong direction. I
didn't realize I could check out phase3 then point Subversion to the
extensions directory in phase3 to check out extensions. I thought Subversion
would get confused, but I just tried it and it worked :-). At least
Subversion performed the checkout. I haven't tried doing an update.
I just (case sensitively) searched the extensions directory for the string
$IP = and found 32 files that compute $IP on their own. How about creating
a standard bit of code that extensions and other modules can copy and use to
figure out MW root. For example, it is very unlikely that the name of the
first level directory (i.e., phase3) will change. The code can call dirname(
__FILE__ ) and then search from the end of the pathname until it finds
phase3. It then knows that the prefix is MW root.
Dan
Since, when... I myself have NEVER setup a mediawiki installation with
the base directory named phase3.
Take a good second look at the chunk of code you posted.
$IP = getenv( 'MW_INSTALL_PATH' );
if ( $IP === false ) {
$IP = dirname(__FILE__).'/../..';
}
This is precisely the reason the MW_INSTALL_PATH environment variable
was introduced. This IS the standard bit of code meant for extensions
that use maintenance scripts to copy.
export MW_INSTALL_PATH=$PWD
php ../extensions/DumpHTML/DumpHTML.php
...
Trust me... I was the one with one of the strangest MediaWiki setups
ever. Symlinks all over the place, multiple extension directories,
multiple svn points, global configs, wiki installations near purely
setup with symlinks to the base files, shell scripts for generating
those installations and upgrading svn points, and so on...
It was basically a personal mini-farm running all my wiki which had
varying extensions setup and varying installations of MediaWiki (latest
stable for most, trunk for the various dev sites).
IIRC, That's how that chunk of code ended up inside MW in the first place.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
