Last modified: 2007-01-16 01:50:23 UTC
I receive this error when I navigate to various pages in my own MediaWiki: Notice: Undefined index: REQUEST_URI in includes\WebRequest.php on line 276 (I think it only occurs when I view Special pages). I just uploaded the wiki last night to a windows machine (I have no control over the machine... it is managed by my hosting provider). I think they are running IIS with php installed as a CGI (however, I am not positive). I have found a solution to this error. The solution I found comes from here: http://tinyurl.com/dvgas It is this: Replace the following function (in includes/WebRequest.php, line 271: /** * Return the path portion of the request URI. * @return string */ function getRequestURL() { return $_SERVER['REQUEST_URI']; } With this one: /** * Return the path portion of the request URI. * @return string */ function getRequestURL() { // Work around REQUEST_URI bug under W2K/IIS/CGI/PHP if (!isset($_SERVER['REQUEST_URI']) and isset($_SERVER['SCRIPT_NAME'])) { $_SERVER['REQUEST_URI'] = $_SERVER['SCRIPT_NAME']; if (isset($_SERVER['QUERY_STRING']) and !empty($_SERVER['QUERY_STRING'])) $_SERVER['REQUEST_URI'] .= '?' . $_SERVER['QUERY_STRING']; } return $_SERVER['REQUEST_URI']; } This is becaue in that IIS is not setting REQUEST_URI in the environment for PHP under CGI mode.
*** Bug 3054 has been marked as a duplicate of this bug. ***
I tried this solution in a similar environment. It helped with some bugs, but our wiki site is still not fully functional--I cannot edit pages. When I save may edits, I am redirected to the page that shows "this is only a preview". If it helps, here's the link http://www.relisoft.com/wiki (I turned off anonymous editing because of spambots, so you have to create an account).
Editing preview problems are due to PHP's session configuration; usually on Windows this is because a default php.ini file ships with a bogus session.save_path value. Make sure this is set to a direction which exists and can be written to.
Another thing, after making the above change, the html output contains links that are formatted differently. For instance, I get: <a href="/wiki/index.php/ReliCodia:How_does_one_edit_a_page" title="ReliCodia:How does one edit a page">how to edit a page</a> instead of: <a href="/wiki/index.php?title=ReliCodia:How_does_one_edit_a_page" title="ReliCodia:How does one edit a page">how to edit a page</a> The question mark was replaced by a slash. I'm not sure if it's relevant, since the links still work.
Bartosz, I'm not a PHP guru by any means, but I would do some debugging with the following line of my bugfix: $_SERVER['REQUEST_URI'] .= '?' . $_SERVER['QUERY_STRING']; I say this because it shouldn't be replacing the ? with /. Perhaps the request isn't making it to this line of the bugfix because it it is contained within an if block: if (isset($_SERVER['QUERY_STRING']) and !empty($_SERVER['QUERY_STRING'])) Maybe IIS is messing something up? Perhaps the isset() function is returning false when it shouldn't? I would do some testing and see if your requests are causing this if statement to be true. This is only speculation.
I get another error when configuring Wiki with IIS. This error is with regard to the LDAP plugin - Notice: Undefined variable: servers in C:\Wiki\mediawiki\includes\LdapAuthentication.php on line 87 Perhaps this is an IIS configuration problem? Or could it be a bug in the plugin? I don't get this error with Apache server. So I'm guessing this is something to do with IIS? Your inputs would be helpful.
(In reply to comment #6) > I get another error when configuring Wiki with IIS. This error is with regard to the LDAP plugin - Notice: Undefined variable: servers in C:\Wiki\mediawiki\includes\LdapAuthentication.php on line 87Perhaps this is an IIS configuration problem? Or could it be a bug in the plugin? I don't get this error with Apache server. So I'm guessing this is something to do with IIS?Your inputs would be helpful. Solved: Replace - function authenticate( $username, $password ) { global $wgLDAPDomainNames, $wgLDAPServerNames, $wgLDAPSearchStrings; global $wgLDAPUseSSL; With - function authenticate( $username, $password ) { global $wgLDAPDomainNames, $wgLDAPServerNames, $wgLDAPSearchStrings; global $wgLDAPUseSSL, $servers;
REQUEST_URI is used in several places in the code, instead of calling WebRequest::getRequestURL. This should probably be fixed as part of this bugfix. Sasha.
I was revamping my site and I accidentally deleted my wiki so the URL ( http://www.mendozamission.com/wiki/index.php?title=Special:Whatlinkshere&target=Main_Page ) doesn't work anymore. Sorry
*** Bug 5404 has been marked as a duplicate of this bug. ***
This bug still seems to exist for 1.7 under IIS. The code in includes/WebRequest.php seems to have changed a little. Here's what I changed it to, and it seems to work: <pre> /** * Return the path portion of the request URI. * @return string */ function getRequestURL() { /* MediaWiki Version 1.7 workaround for http://bugzilla.wikimedia.org/show_bug.cgi?id=3000 Original code: $base = $_SERVER['REQUEST_URI']; Replaced with: */ if (!isset($_SERVER['REQUEST_URI']) and isset($_SERVER['SCRIPT_NAME'])) { $base = $_SERVER['SCRIPT_NAME']; if (isset($_SERVER['QUERY_STRING']) and !empty($_SERVER['QUERY_STRING'])) $base .= '?' . $_SERVER['QUERY_STRING']; } /* End new code */ if( $base{0} == '/' ) { return $base; } else { // We may get paths with a host prepended; strip it. return preg_replace( '!^[^:]+://[^/]+/!', '/', $base ); } } </pre>
*** Bug 8574 has been marked as a duplicate of this bug. ***
Created attachment 3072 [details] Untested patch against r19274 I can't test this on IIS myself until I figure out how to get my XP Pro installation out of a VirtualPC gulag; would appreciate feedback before I commit this. :)
Brion Vibber: That patch looks awesome! (I just got done reading it). However, like you, I don't have a currrent MediaWiki setup to test this out on. However, you can get windows 2003 server on a virtual pc virtual hard disk from microsoft: http://www.microsoft.com/windowsserver2003/evaluation/trial/default.mspx (30-day evaluation). If you are willing to install Win 2003 server in a VM yourself, you can download a 120-day evaluation ISO: http://www.microsoft.com/windowsserver2003/evaluation/trial/ viewtrialoptions.mspx#EQH I hope this helps! -- Nathan
Aha, now an ISO I should be able to get running in Parallels... thanks!
Ok, confirmed the problem on IIS 6 under Win2k3, with PHP 5.2.0 running as CGI. (It seems fine running as an ISAPI module.) Confirmed that the patch appears to fix problems; install, a bit of surfing around, recentchanges, editing seem to work. No visible notices anymore with error reporting and display_errors tweaked up, and the special page tab includes the expected URL variables. Applied on trunk in r19321, and in REL1_9 as r19322 since it looks not too disruptive. Will be in 1.9.1 point release.