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
On Wed, Aug 12, 2009 at 4:39 PM, dan nessettdnessett@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 note....can 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
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
--- On Wed, 8/12/09, Brion Vibber brion@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
On Wed, Aug 12, 2009 at 6:04 PM, dan nessettdnessett@yahoo.com wrote:
--- On Wed, 8/12/09, Brion Vibber brion@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
dan nessett wrote:
--- On Wed, 8/12/09, Brion Vibber brion@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 lists@nadir-seen-fire.com [Wed, 12 Aug 2009 15:33:50 -0700]:
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.
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 should be much more reliable than just looking for specific dir name. Also, that would be compatible with multiple MW installations.
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.
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). Dmitriy
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 agarrett@wikimedia.org http://werdn.us/
On Thu, Aug 13, 2009 at 05:16, Dmitriy Sintsovquestpc@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/
* Leons Petrazickis leons.petrazickis@gmail.com [Thu, 13 Aug 2009 10:35:51 -0400]:
On Thu, Aug 13, 2009 at 05:16, Dmitriy Sintsovquestpc@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
On Wed, Aug 12, 2009 at 5:03 PM, Brion Vibberbrion@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"?
On 8/12/09 6:43 PM, Aryeh Gregor wrote:
On Wed, Aug 12, 2009 at 5:03 PM, Brion Vibberbrion@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
On Thu, Aug 13, 2009 at 5:16 AM, Dmitriy Sintsovquestpc@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 Vibberbrion@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
On 8/13/09 10:55 AM, Aryeh Gregor wrote:
On Thu, Aug 13, 2009 at 1:06 PM, Brion Vibberbrion@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
On Thu, Aug 13, 2009 at 2:25 PM, Brion Vibberbrion@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 Karonennospam@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.tongminh@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/.
On 8/13/09 3:32 PM, Aryeh Gregor wrote:
On Thu, Aug 13, 2009 at 2:25 PM, Brion Vibberbrion@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
On Thu, Aug 13, 2009 at 7:40 PM, Brion Vibberbrion@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?
On 8/13/09 4:51 PM, Aryeh Gregor wrote:
On Thu, Aug 13, 2009 at 7:40 PM, Brion Vibberbrion@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
On Thu, Aug 13, 2009 at 9:12 PM, Brion Vibberbrion@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.
2009/8/14 Brion Vibber brion@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)
Aryeh Gregor wrote:
On Thu, Aug 13, 2009 at 3:24 PM, Ilmari Karonennospam@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.
I confess that we have our extensions in /usr/local/wiki-extensions, which is an svn checkout of our local repository. For us, it makes two things easier: 1) I've been known to stupidly delete the extensions directory when upgrading MW 2) different wikis share the single directory.
But when something breaks, and I suspect it's because it needs javascript or css, I try putting it in the extensions directory.
Jim
On Aug 13, 2009, at 11:25 AM, Brion Vibber wrote:
On 8/13/09 10:55 AM, Aryeh Gregor wrote:
On Thu, Aug 13, 2009 at 1:06 PM, Brion Vibberbrion@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
===================================== Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054
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.
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 Vibberbrion@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
On Thu, Aug 13, 2009 at 3:43 AM, Aryeh GregorSimetrical+wikilist@gmail.com wrote:
On Wed, Aug 12, 2009 at 5:03 PM, Brion Vibberbrion@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
On Thu, Aug 13, 2009 at 4:17 PM, Bryan Tong Minhbryan.tongminh@gmail.com wrote:
On Thu, Aug 13, 2009 at 3:43 AM, Aryeh GregorSimetrical+wikilist@gmail.com wrote:
On Wed, Aug 12, 2009 at 5:03 PM, Brion Vibberbrion@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@lists.wikimedia.org