WordPress MU

For me, this was all about GODADDY - not being able to access something on the server, and so now that I am on virtual hosting on a different hosting provider

ITS FINALLY WORKING THANK YOU ANDREA!!!!!

I wonder if there's something about the host software causing an issue.

I can't dupe the error and I'm using ie 6 and 7 half the time.

Is anyone seeing anything in their webserver's error logs?

Negative.

Hi dr. mike: I am happy to give you access to the godaddy site/hosting if you want to see how the heck it happens...let me know. I can setup the install just like I did and Im sure I can dupe it..but its got to be something about GoDaddys software (and we know how much you love them). It worked like peaches at the alternate hosting provider. I know it can't be GD alone, tho, cuz other people having the issue were not all at godaddy. Its got to be something particular - perhaps to shared hosting, altho I seem to recall that many said they weren't having the issue using shared hosting.

J

Same problem here.

Shared hosting on 1&1
Works in Firefox 2.0.0.4 and not in IE 7.0.6000.16473
Fresh install, only change to htaccess was add php5 and www rewrite.
It appears IE7 is redirecting the page to a 404, like it hits a line of code in the page and then forwards off to 404.

v.1.2.3 of mu

I run Godaddy shared hosting and was having the same problem, only in IE. WBNiko's suggestion to add this line in the .htaccess file at the top worked.

AddType x-mapp-php5 .php

As he said, this will work only if your host allows PHP5

Thanks!

For what it's worth:

THIS IS NOT AN IE PROBLEM.

Sorry, I know that's considered shouting and all, but I wanted folks skimming the page to see it.

If you check the headers being sent to the browser, the header being sent (for wp-signup.php, at least) is "404 OK". The same header gets sent no matter what browser you use.

The browser difference is that when IE sees this header, it replaces the page's content with it's "helpful" 404 screen, whereas Firefox displays the page content regardless of the header.

Oddly enough, the "AddType" suggestion fixed IE's behavior for me (I'm on GoDaddy too, regretfully), but only intermittently, because it still did not change the header. The header still gets sent as "404 OK."

I'm wondering if the 404 header was put there intentionally to discourage spamming or something by keeping the wp-signup.php out of search engines.

Regardless, if you want to ensure that a 200 header gets sent and not a 404, place this code into a file and drop it into mu-plugins:

<?php
/*
Plugin Name: WP Signup 200
Plugin URI: http://adambrown.info/
Description: Ensures a 200 header (not 404) on WPMU's wp-signup.php
Author: Adam R. Brown
Author URI: http://adambrown.info
*/

function wpSignupEnsure200(){
	header("HTTP/1.0 200 OK");
}

add_action( 'signup_header', 'wpSignupEnsure200' );
?>

No 404 header on my site - works fine on IE too

So you're saying that MU is causing a 404 header to be sent, and IE is handling it like it would any other 404.

Do you have any basis on the environment that is causing this? Is it a particular php version, apache version, etc?

Reason being, I can't reproduce this "404", and it works just fine on my boxes in IE 6/7.

Not saying there isn't a problem, but sending a http/1.0 header may/may not be the best answer. For example, what if its http/1.1 and not 1.0?

So I guess the question is, is it the server or MU?

If it were MU, then it would do it everywhere, and not just in select instances. So, where is the 404 header coming from would be a better place to start.

I don't know whether it's MU or godaddy producing the error, I just know that something is sending it, and that the plugin seems to fix it. Since other folks don't have the same problem, my money is on GoDaddy's setup.

As for the 1.0/1.1 thing, I leave it to individual users to figure out which they need to send.

edit:

From your quotes around "404", I sense you might question whether I'm correct. I confirmed the header in a few ways. The easiest is to use http://web-sniffer.net/ but I also use a Web Developer toolbar in Firefox to check the header. So yes, there really is a 404 being sent. Maybe not on every WPMU setup, but this is 1.2.5a doing it, so it's not an outdated issue.

I'm on 1.2.5.a on PHP/5.2.3 and Apache/2.0.48 and wp-signup.php always returns 1.1 in the header - web-sniffer reports /wp-signup.php HTTP/1.1[CRLF] no matter which way I call it which would suggest its GoDaddy or something in your configuration

Honestly, the 1.0/1.1 thing isn't really my area of expertise. Change it to 1.1 in my little plugin code if you want. Now that I look at it, even though I wrote "1.0" in my code, it's a 1.1 being sent, so that's being overridden anyway.

The point is that I was changing 404 to 200; the 1.0 thing is just a red herring.

But why are you getting a 404 sent? Its not normal behaviour from WPMU as its not being seen by the majority of people on here.

Sorry Adam, but the "404" was more for mystery than validity.

That being said, the root cause still needs to be addressed, and it's pretty convincing it's the server at the moment.

so glad i found this thread. was getting really worried. at first i thought it was my theme i picked, so i went back to the default themes and the same issue, 404 everywhere with wp-signup.php. I was freaking out that I might be jumping ship with MU. the AddType x-mapp-php5 .php seems to have fixed my issue. thanks to all for that fix. i hope it continues to work!

1and1 shared hosting, php5, MySQL5.0, apache

I contacted Godaddy and the guy said I should change the permissions. He wasn't sure what I should change them to, and frankly, I'm not eiter, but I put it at 777 on wp-signup.php and IE appears to be handling it fine now.

Correction. It's now being inconsistent again. I used the plugin given above and it's now working.

hey guys,

I have this same problem, but it is with the Calendar plugin by Kieran O'Shea.

It seems to me, the common players here are using shared hosting, the kind that makes use of a "public_html" folder, and a symbolically linked "www" folder.

Is your htaccess file is stripping the www from your domain?

I think these combinations of factors lead the server to respond with 404, and a page.

However - I do NOT pretend to understand htaccess, so at this point i will gracefully bow out and hope this info spurs someone on to some new ideas.

thanks, tre

ps - the calendar plugin also makes a change to htaccess - and incidentally, it knocked out the existing rule to strip out the "www" - i think because of htaccess losing inheritance.

when i would go to regular pages within the blog, the "www" would be stripped correctly - but if i went to the calendar (the htaccess rewritten) page - THEN it would not strip out the "www" from the url when i typed that in.

therefore, i put some rules back into the htaccess file to once again strip out the www, and it worked. BUT, still no luck getting the calendar pages to display in IE.

So, at least I fixed the www redirect problem, but not yet the 404 issue.
methinks they are related though....

I

so adam brown, in the meantime (please) - how would one go about using your "forced" 200 header, for an altogether different plugin...?

if your still around...

thanks

adamrbrow - thanks. I am on godaddy and had the same problems everyone has mentioned here. Plugin works like a charm!

I'm having problems with this as well. I had our web admin update the Apache config file conf/mime.types to add the line

AddType x-mapp-php5 .php

That didn't work.

I also tried putting Adam Brown's WP Signup 200 file into mu-plugins but that didn't do anything either.

Anything else I could try? This only started happening with the last few blogs that were created. Prior to that, all new blogs loaded fine in IE. Now the new ones don't. Old ones that did load in IE continue to do just fine.

This seems to be an old problem so is this not happening to people anymore? It's happening to me on hostmonster. I haven't been able to find anything in the WPMU code that would be sending a 404 response.

Ok everyone, I have been having this problem for sometime now.

I tracked it down to the wp() call in wp-blog-header.php So for now I've just commented out the line that includes wp-blog-header.php and it works fine.

I have no idea why wp() (from functions.php) would matter in this case--it would take someone more familiar with the code. But since it seems that it fixes the problem with no ill side-effects, I guess I'll keep it for now.

Finally chiming in here - none of these options are working for me, yes the site is on godaddy, no there's no option of moving it. (it's part of a large established site)

Narrowing things down a little - if the link to the signup page is clicked on from the main page, it works. If accessed directly, it doesn't work in IE. It throws a "page not found" in the header in FF, but displays the page.

Still haven't foun out the *why* of why it's doing this (which is driving me crazy not knowing), but as to what really works:

in wp--blog-header,php, instead of commenting out wp();, which killed all the posts in all the blogs, put in this:

if(strpos($_SERVER['REQUEST_URI'],'wp-signup.php') === false) { wp(); }

And don't thank me, thank Mr Andrea, a.k.a Ron. :P

I see. That's interesting. Do you know why he (Ron) put the if statement there? It seems to work fine without wp() at all... what does the call to wp() do? Maybe this should be submitted as a patch if it seems to be the right solution.

I don't think it's patch-worthy as it's server specific.

I can't remember what the wp(); does. :-/