Last modified: 2011-12-15 07:39:27 UTC
patch need-review If OK generally (it works for me), pls replace includes/DefaultSettings.php's $wgScriptPath = '/wiki'; with e.g. // -10 clips off the /index.php to leave, e.g., /mediawiki-x.y.z $wgScriptPath = substr($_SERVER["SCRIPT_NAME"], 0, -10); Thanks
I think this would break if you're accessing the wiki through compatibility inpoints like index.php5 or wiki.phtml, or one of the alternate inpoints like api.php, img_auth.php, or load.php.
The fact that substr is being used when dirname trivially does what the author was actually intending is definitely messed up. However that doesn't mean this isn't messed up. We're trying to move AWAY from dynamic auto detection like this. It messes up in edge cases; It breaks on cli scripts (likely why our installer now fills out $wgServer instead of auto-detecting it all the time). This kind of thing will break on any non-root entrypoint, eg: One defined by an extension (something I'm actually trying to make easier to do, not extremely fragile and easy to break). In the end the default for $wgScriptPath is nothing but a worthless dummy value, we could probably just set it to null for all it matters. $wgScriptPath should ALWAYS be defined inside LocalSettings.php
My PHP's rusty, so I didn't immediately remember dirname(): $wgScriptPath = dirname($_SERVER["SCRIPT_NAME"]); If the goal is to help people get MediaWiki working as easily as possible, as it should be, we should have as intelligent, auto-detecting defaults as people are willing to code. Those interested in speed (or what is your goal?) are free to then hone. (Until there's a wizard to generate hard coded settings for LocalSettings.php that obviates DefaultSettings.php entirely, a wizard that MediaWiki offers to run on errors that suggest bad settings, such as occur after moving a site.)
(In reply to comment #3) > My PHP's rusty, so I didn't immediately remember dirname(): > $wgScriptPath = dirname($_SERVER["SCRIPT_NAME"]); > That won't work on Windows.
(In reply to comment #3) > If the goal is to help people get MediaWiki working as easily as possible, as > it should be, we should have as intelligent, auto-detecting defaults as people > are willing to code. Those interested in speed (or what is your goal?) are > free to then hone. (Until there's a wizard to generate hard coded settings for > LocalSettings.php that obviates DefaultSettings.php entirely, a wizard that > MediaWiki offers to run on errors that suggest bad settings, such as occur > after moving a site.) My goal is to ensure that MediaWiki is not fragile enough to break simply because an extension defines a new entry point. As it stands with the pattern you are suggesting if an extension defines an entry point like /extensions/FooBar/baz.php the SCRIPT_NAME will be /extensions/FooBar/baz.php, then $wgScriptPath will become "/extensions/FooBar" and suddenly every link generated from that entrypoint breaks. And to top it off We're also trying to ensure that when someone tries to run a cli script their configuration actually has enough information to function. Trying to auto-detect $wgScriptPath will give cli scripts even 'less' information and some of them won't be able to function (as I said, this is likely why the new installer now sets $wgServer) And you're arguing two different things. We already have a system for getting running quickly, the installer. And it does auto-detect this information and then adds that to the LocalSettings.php that it generates. Wikis that have moved are a different case. In fact if a wiki moves, and it's ScriptPath changes, then it likely has other changes that have to make anyways, ones we can't do for them. Like rewrite rule updates, etc... You should actually compare what it takes to move your wiki in a way that changes the domain/path to other CMS systems at the same level as MW. For MediaWiki you usually just have to modify one or two config variables. WordPress on the other hand will happily save urls hardcoded with a domain and path in them all over the database in ways that complicate the move and force a pile of changes to the db. In fact last time I tried to setup a beta. subdomain copy of WordPress I found that the base url config was stored inside the database instead of a config file and WordPress was coded in such a way that you couldn't even log into the wp-admin area to change that setting and hence had to manually fix it in the database.
(In reply to comment #4) > (In reply to comment #3) > > My PHP's rusty, so I didn't immediately remember dirname(): > > $wgScriptPath = dirname($_SERVER["SCRIPT_NAME"]); > > > > That won't work on Windows. It is working on MediaWiki 1.15.1 on XAMPP 1.7.7 on Windows 7. (In reply to comment #5) > My goal is to ensure that MediaWiki is not fragile enough to break simply > because an extension defines a new entry point. > As it stands with the pattern you are suggesting if an extension defines an > entry point like /extensions/FooBar/baz.php the SCRIPT_NAME will be > /extensions/FooBar/baz.php, then $wgScriptPath will become "/extensions/FooBar" > and suddenly every link generated from that entrypoint breaks. Let us focus. Does calculation of an autodetecting $wgScriptPath default cause a problem when a valid $wgScriptPath setting in LocalSettings exists? If it doesn't (and it won't with IFs checking for the relevant environmental conditions, like CLI), all we have done with autodetection is increase the generality of our default, and lost nothing. No? When the default value doesn't work, the administrator will simply have to set the value manually, just as currently. But in the meantime, their MediaWiki is more likely to work, entirely or sometimes. Additionally, if/when the wiki doesn't work will provide the admin with important clues absent from the universal breakage that results for a completely non-functioning $wgScriptPath. What we have now is a MediaWiki that, after a site move within XAMPP that does not include a diligent updating of $wgScriptPath, hands the browsing user the XAMPP homepage unconditionally, which is really very little info with which to find and fix their wayward $wgScriptPath. No?
>Additionally, if/when the wiki >doesn't work will provide the admin with important clues absent from the >universal breakage that results for a completely non-functioning $wgScriptPath. > What we have now is a MediaWiki that, after a site move within XAMPP that does >not include a diligent updating of $wgScriptPath, hands the browsing user the >XAMPP homepage unconditionally, which is really very little info with which to >find and fix their wayward $wgScriptPath. No? Umm, changing it in DefaultSettings.php wouldn't fix that, as 99.9% of users have it set to something explicit in LocalSettings.php (since its done automatically) so the auto-detection would just be overridden anyhow. I'm doubtful we'd stop auto-setting it in LocalSettings.php, so doing this wouldn't have any affect for anybody really. I also agree that auto-detecting that sounds scary, there's a lot of edge cases where that could go wrong (in the substr example, if the php extension is .php5 instead of .php for example) Its better to have something that works all the time, then something that fails every now and then for some folks. Its not an unrealistic burden to require users to modify this setting in the rare event they move what directory their install is in. >It is working on MediaWiki 1.15.1 on XAMPP 1.7.7 on Windows 7. When I hear won't work on windows, I would assume IIS is meant.
