For awhile we've supported automatic detection guessing if the webserver supports PATH_INFO and if so automatically using /index.php/$1 for the article path. I believe this even predates our better REQUEST_URI handling.
I'm considering the idea of dropping support for this automatic setup.
There are a few faults to this feature we have.
Firstly there are cases where it may break. And I don't mean simple graceful breakage. I mean it is possible for us to detect support incorrectly on a slightly misconfigured webserver setup and when that happens we outputs a fatal page telling the user they have to add some config to their LocalSettings.php in order to get their wiki to even work. So you can end up installing MediaWiki, following the "enter your wiki" link, and end up on a big white plaintext page telling you your wiki was broken from the start.
It can also cause problems when you change hosting. We detect this automatically based on whether the current server supports it. This isn't like short urls where the user sets up the configuration and practically every single server that exists will support configuring it. In this case because we auto-detect it if you move from a server setup that supports /index.php/Foo and then move to something using say FastCGI where it doesn't work by default all of a sudden your urls change. And not just change, every url that people have bookmarked becomes invalid.
And of course it creates a bit of a negative incentive. Because /index.php/Foo is so simple and works out of the box people lazily don't bother to setup proper short urls. The short url they have is only slightly shorter. It 'still' is hardwired to architectural facts like the filesystem and the fact we're using .php.
----
So I'm considering dropping this automatic feature. Making this change will mean that MediaWiki will start outputting /index.php?title=... style URLs for everyone who hasn't configured short urls.
A few important notes: - This will NOT break existing wikis. We may still leave the actual fallback PATH_INFO detection in place. And REQUEST_URI will always keep the implied /index.php/$1 inside the PathRouter. So even though we won't be outputting /index.php/Foo style urls if the wiki previously supported /index.php/Foo all those urls will still point to the pages. The links we output will just start using ?title=. - While we won't be doing anything automatic anymore anyone obsessed with having /index.php/Foo can still simply set `$wgArticlePath = "/index.php/$1";` if it works on their server.
----
What are peoples thoughts on this plan?
On 25 March 2012 10:30, Daniel Friesen lists@nadir-seen-fire.com wrote:
And of course it creates a bit of a negative incentive. Because /index.php/Foo is so simple and works out of the box people lazily don't bother to setup proper short urls. The short url they have is only slightly shorter. It 'still' is hardwired to architectural facts like the filesystem and the fact we're using .php. What are peoples thoughts on this plan?
It's not clear if you plan to break this on existing installations - breaking backward compatibility in an upgrade is infuriating behaviour and will serve as an incentive not to upgrade, leaving insecure installations in the wild.
What is the big win from doing this? Do you just want to remove it because it's messy and doesn't work perfectly?
- d.
On Sun, 25 Mar 2012 10:18:12 -0700, David Gerard dgerard@gmail.com wrote:
On 25 March 2012 10:30, Daniel Friesen lists@nadir-seen-fire.com wrote:
And of course it creates a bit of a negative incentive. Because /index.php/Foo is so simple and works out of the box people lazily don't bother to setup proper short urls. The short url they have is only slightly shorter. It 'still' is hardwired to architectural facts like the filesystem and the fact we're using .php. What are peoples thoughts on this plan?
It's not clear if you plan to break this on existing installations - breaking backward compatibility in an upgrade is infuriating behaviour and will serve as an incentive not to upgrade, leaving insecure installations in the wild.
What is the big win from doing this? Do you just want to remove it because it's messy and doesn't work perfectly?
- d.
- Removing this autodetected feature will avoid breaking wikis out of the box. - 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";`
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.
- 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.
On 26 March 2012 10:45, David Gerard dgerard@gmail.com wrote:
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.
What I'm asking for: if you change this to no longer be the default URL, then please make it so that, by default, previous site.name/index.php/articlename URLs *continue* to Just Work.
If someone innocently upgrades from the tarball, breaking legacy URLS on their intranet strikes me as bad practice.
- d.
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.
On 26 March 2012 11:31, Daniel Friesen lists@nadir-seen-fire.com wrote:
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.
OK, that answers my worry :-)
- d.
On 25/03/12 11:30, Daniel Friesen wrote:
So I'm considering dropping this automatic feature. Making this change will mean that MediaWiki will start outputting /index.php?title=... style URLs for everyone who hasn't configured short urls.
I don't like dropping that. We could try making automatically a .htaccess for short urls, but that isn't coherent now that we stopped creating LocalSettings.php. And providing a .htaccess in the tarball doesn't look like a good idea, either (and note we want it *above* the mediawiki folder). Moreover, we would need testing to check that .htacces is indeed working, although that could be solved with a config/.htaccess and some install check.
See all the regrets caused now by autodetecting, etc. hand holding. That's what happens when you don't stay within the proper bounds of your program's main purpose. And now you even talk of creating .htaccess files for people... Just more regrets later. I've just stuck with the real URLs (title=...) and haven't looked back since.
* Platonides Platonides@gmail.com [Mon, 26 Mar 2012 00:51:59 +0200]:
On 25/03/12 11:30, Daniel Friesen wrote:
So I'm considering dropping this automatic feature. Making this change will mean that MediaWiki will start outputting /index.php?title=... style URLs for everyone who hasn't configured
short
urls.
I don't like dropping that. We could try making automatically a .htaccess for short urls, but that isn't coherent now that we stopped creating LocalSettings.php. And providing a .htaccess in the tarball doesn't look like a good idea, either (and note we want it *above* the mediawiki folder). Moreover, we would need testing to check that .htacces is indeed working, although that could be solved with a config/.htaccess and
some
install check.
.htaccess directory specific rules might be disabled in httpd.conf virtualhost settings. Also .htaccess will not work for nginx (and probably for IIS as well). Dmitriy
wikitech-l@lists.wikimedia.org