On Mon, 26 Mar 2012 02:45:37 -0700, David Gerard dgerard@gmail.com wrote:
On 26 March 2012 08:15, Daniel Friesen lists@nadir-seen-fire.com wrote:
- Removing this autodetected feature will avoid breaking wikis out of
the box.
Right - what is the extent of the breakage you're seeing in new installs?
'Cos in the general use case (apache with mod_php), it's the way Mediawiki works out of the box by default, it Just Works and so there's a huge backward-compatibility pile of wikis with this URL format.
The only thing going away would be the autodetection that makes us output urls like this automatically. Existing bookmarks to /index.php/Foo style urls will still function.
Take a look at what we have in Wiki.php and WebRequest.php: https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob;f=includes... https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob;f=includes...
Quite frankly PATH_INFO for a long time has been a completely unstable thing to rely on.
This issue of course is not a huge percentage. I see a lot of reports of issues being related to ISS or use on Windows. However I believe that one of the php configuration variables can also trigger the issue. Namely I believe it may show up on some shared hosts that use some form of (fast)cgi setup for their Apache configuration.
The point is not how common it is. It's how bad it is. The way the autodetection is setup, if you are one of the ones unlucky enough to have a problem server; after going through the entire wiki installation process and going in to visit your wiki you will be greeted by an error page out of the box. And that error page is not due to a minor issue. We fatal out on this so early because the issue this configuration causes is an infinite redirection loop we can only detect when it actually happens that makes it completely impossible for the wiki to work.
So it's "We don't want to edit our configuration to make /index.php/Foo work" vs. "Autodetection for /index.php/Foo support breaks my wiki right after I install it."
- Users who insist on /index.php/Foo style urls now have to opt-in to
something that could shoot them in the foot by actually configuring MediaWiki to use `$wgArticlePath = "/index.php/$1";`
Again, this looks very like a personal aesthetics argument.
- d.
Asthetics is /almost/ my mention of /index.php/Foo still having the faults of long urls. Urls that completely break after installation on some servers and make your bookmarks non-functional simply by changing server software are not aesthetic issues.
I should also mention the only other unstable autodetection like this I can think of we've had is $wgServer. And we've dropped relying on autodetection of that by default. It's also not something that breaks in the way this does.