robchur wrote:

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.

robchur wrote:

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.

ybarthelemy wrote:

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.

ybarthelemy wrote:

To do it, just replace :

If using PHP as a CGI module, use the ugly URLs.

with

1. If using PHP as a CGI module, use the ugly URLs. To restore
2. pretty URLs, make sure to also set $wgUsePathInfo to true.

robchur wrote:

(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.

ybarthelemy wrote:

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.