robchur wrote:

*** Bug 3054 has been marked as a duplicate of this bug. ***

bartosz wrote:

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.

bartosz wrote:

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.

nathan wrote:

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.

mailsarith wrote:

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.

mailsarith wrote:

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

sashagim wrote:

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.

nathan wrote:

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

jyoung wrote:

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>

m.bogle wrote:

*** Bug 8574 has been marked as a duplicate of this bug. ***

Created attachment 3072
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. :)

Attached:

nathan wrote:

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.