404 error while saving options

[Ishbir]

There is bug in options.php (not options-general.php) which redirects to ​http://www.example.com/wp-admin/updated=true. That should redirect to ​http://www.example.com/wp-admin/options-general.php. I have already made its fix. You may have it at ​http://www.ishbir.com/wpfix1.zip. The fix was in the line

$goback = add_query_arg('updated', 'true', $_SERVER['HTTP_REFERER']); 

Whereas, it had to be

$goback = add_query_arg('options-general.php?updated', 'true', $_SERVER['HTTP_REFERER']);

I have already fixed it to make it easier for you to search thousands of lines of code. Please include this fix in your next version of Wordpress.

Regards,
Ishbir Singh

[tereshchenko]

A variation of this bug happened for me with all "Options" pages (I used version from "2.0" branch - yesterday, 23:00GMT). Instead of normal address I was redirected to the address without "​http://" part (which is obviously treated by server as non-existing filename).

[Nazgul]

Diff based on wpfix1.zip by reporter

[Nazgul]

I've been unable to reproduce this on both my own blogs (2.0.3 and SVN), but other people on the support forums have reported this issue as well.

See also ​http://wordpress.org/support/topic/75064 and ​http://wordpress.org/support/topic/34165

[ryan]

That fix will probably break the goback for the other options pages that use options.php. Referrers need to be enabled for all of the redirects to work.

[tereshchenko]

I compared files in 2.0.2 (which worked fine) and current SVN - and found that add_query_arg() function was modified for 2.0.3

Following code was added:

	if ( preg_match('|^https?://|i', $uri, $matches) ) {
		$protocol = $matches[0];
		$uri = substr($uri, strlen($protocol));
	} else {
		$protocol = '';
	}

I suspect the issue's in it.

[tereshchenko]

Correction - it was modified after 2.0.3 (which worked fine for me BTW).

[tereshchenko]

So protocol is removed from the URI:

$uri = substr($uri, strlen($protocol));

and kept in variable $protocol - which is never used again (which I think means that new URL will be without ​http:// part).

[ryan]

Good catch. That change wasn't properly ported from trunk. [3905]

I'm not sure this is the same issue as the orginal reporter's though.

[tereshchenko]

Yep, that is fix for my problem only :-)

Then again, thinking of original issue - looks like such situation possible only when $_SERVERHTTP_REFERER? is empty string. In this case the result of the function will be updated=true and this will be treated as a file in /wp-admin/ directory.
So to fix this either users should trash their incompetent firewalls, or whitelist their own website, or WordPress shouldn't rely on referer in such redirects.

[ryan]

The problem encountered when referrers are disabled is fixed by a new method of passing referrers. See bug #2800 for details. The commits for that bug fix the options 404 issue for both trunk and the 2.0 branch.