Last modified: 2010-05-15 15:33:29 UTC
cgi was detected in php_sapi_name() and MediaWiki prevented my host to use it, resulting in infinite loop. The story follows : I have set up MediaWiki in local and have made a script using MediaWiki. This script uses the cool URLs : http://server/index.php/Article. When I finished, I upload all that on my web hosting service, I re-configured MediaWiki on that server, and my script links were redirected on home of MediaWiki, with an ugly URL. So, I checked LocalSettings and saw : $wgArticlePath = "$wgScript?title=$1"; I changed it to $wgArticlePath = "$wgScript/$1"; in the hope my URI would worked (I was very optimitic, since it is a string modification, and not a TRUE/FALSE modification... And, it didn't worked, it does infinite redirection instead of just displaying the article. The 'error' is first to assume that if php_sapi_name() returns something with CGI, PATH_INFO can't work. This is false, in absolute. A possible workaround is to add this option in LocalSettings with a comment about that. An other way is to find an other way to check the support of path_info. An other way is to modify WebRequest to ignore wgUsePathInfo (but please don't do that, since it's crap...)
PHP running as a CGI binary causes the pretty URLs not to work. That's why the configuration script sets the $wgArticlePath value to the ugly ones when it detects this. These cases have been tested. If you went and changed the value against the recommendation, and this broke your MediaWiki installation, that's your fault and not the software's. Try it with the ugly URLs and see if this works. Resolving INVALID.
Just to be clear about it: the installer script forces the change once, when writing out the configuration file. The software doesn't enforce it elsewhere.
There is no bug in MediaWiki about that that is just a possible enhancement. Sorry if I was not clear about that. The problem is that MediaWiki can run with pretty URLs enabled in some cases. I was not saying it was not my fault, It was since I wanted to force the use of pretty URLs. I just recommanded to provide user a way to restore pretty URLs even if CGI was detected. In my case, pretty URLs work perfectly with MediaWiki, but MediaWiki prevented them to work by setting it to false by default for CGI installation : $wgUsePathInfo = ( strpos( php_sapi_name(), 'cgi' ) === false ); Adding $wgUsePathInfo = false; in LocalSettings during installation with a comment specifying : Pretty URL was disabled because your server is running PHP as a CGI binary. If you want to restore pretty URLs despite that, please make sure to set $wgUsePathInfo to true. Doing this will allow unexperienced user to restore pretty URL support if possible, knowing this might not work.
To do it, just replace : ## If using PHP as a CGI module, use the ugly URLs. with ## If using PHP as a CGI module, use the ugly URLs. To restore ## pretty URLs, make sure to also set $wgUsePathInfo to true.
(In reply to comment #3) > was detected. In my case, pretty URLs work perfectly with MediaWiki, but MediaWiki prevented them to work by setting it to > false by default for CGI installation : > $wgUsePathInfo = ( strpos( php_sapi_name(), 'cgi' ) === false ); No, what it set was $wgArticlePath = "$wgScript?title=$1" as opposed to "$wgScript/$1" because _PRETTY URLS DO NOT NORMALLY WORK WHEN PHP IS RUN AS A CGI BINARY_. If users _know_ that pretty URLs can work, then they simply change this setting and save LocalSettings.php. It's even commented so they know they can do that.
Since $wgUsePathInfo would be set to false, even if a user changes $wgArticlePath, this will not work. MediaWiki will ignore the PATH_INFO, and do infinite redirects unless $wgUsePathInfo is set to true. According, my investigation, by default, each time a page is requested, $wgUsePathInfo is computed, and set to false if the server is running a CGI. Then, when a user request a page using path info (a pretty URL), which is the case with pretty URLs, WebRequest.php will ignore it, and index.php will try redirect to Home (which is impossible using pretty URL, since this will be ignored by MediaWiki, and will generate an infinite loop). The worst is when a user request a page using a pretty URL, whether $wgArticlePath is set to pretty or ugly URL, he will be redirected to home rather to the page he requested, that is an unexpected behaviour. In my opinion, this URL should have been processed, and eventually redirected to an ugly URL if needed. In my opinion, $wgUsePathInfo should be always set to true, unless $_SERVER['PATH_INFO'] can contains garbage, which I don't think that is the case.
