Partner and Community Forums
Buddypress 404 error
Last post Jan 30, 2011 03:19 PM by rbaccaro
Mar 03, 2010 10:59 PM|LINK
I've had Wordpress MU installed for over a year on IIS 6, and I recently set up Buddypress 1.2. I had 1.0.X versions of Buddypress installed before this, which seemed to work, but I decided to wait for subsequent versions to actually use it.
I'm having trouble with 404 errors that seem to be related to URL rewriting. I have Micronovae's Mod_Rewrite Pro installed, which has always worked for Wordpress MU. When I click "create a group" on any computer other than the server, I am given a 404
error on both IE8 and Firefox. However, if I click "create a group" on the server, using the same URL, it works perfectly on both IE8 and Firefox. Does anyone have any idea why it would work on the server, but not anywhere else? There are several other
sites hosted on this server, so I was thinking it could be a host header problem, but I don't see anything wrong with my set up. I am using the standard .htaccess file for Wordpress MU installed in a root folder. Blogs are set up as subfolders, not subdomains.
I started off using ISAPI PHP, but I have switched to FastCGI as one attempt to diagnose the problem. I'm using the newest PHP 5.3. I've talked with Micronovae and they don't think it is a problem with their product. There are similar problems on the
Buddypress forums, but nothing exactly like I have, and there aren't many solutions, nor a lot of expertise with IIS.
Mar 04, 2010 12:44 AM|LINK
Can you disable rewriting and try to access the pages from a remote server and ensure that the access to the pages is available? This might also rule out rewrite as the cause.
Mar 04, 2010 04:52 AM|LINK
I think I found the problem, although I don't know how to fix it. If I disable "friendly http error messages" in IE., it works correctly. This was disabled on the server's browser by coincidence, which is why it worked. When I disable it on other computers it
also works. The one firefox browser that I tried had the google toolbar installed, which intercepts errors in much the same way.
I'm really fuzzy on how all of this is supposed to work. This is my best shot: The user clicks a button which goes to
http://fqdn/groups/create. That doesn't exist and the server is supposed to forward them to
http://fqdn/groups/create/step/group-details/, which is the first step in the creation of a group. When "friendly http error messages" is enabled, IE blocks the redirect. If I go straight to the "group-details"
url it works fine.
I suspect that this is the reason for the problems that a few people have been reporting with buddypress on IIS. I don't know any solution because the only thing that I've read to get around this, other than disabling friendly http error messages, is to
make sure the error message is at least 512 bytes, but I don't know how rewriting fits into all of this. The page that they are redirected to is many times that.
Mar 04, 2010 10:20 PM|LINK
It appears the application is sending you a 404 status code while still navigating to a page. This is probably intended by the authors of the application. I would imagine though that since they are sending a 404, the application was unable to find it's true
target and thus defaulted back to the page you see now.
Mar 06, 2010 09:38 PM|LINK
Unless I misunderstand, Buddypress/Wordpress is able to find its true target which is why it works with the "friendly" messages turned off. The web browser is being confused by something and is interrupting the redirect.
Mar 08, 2010 04:48 PM|LINK
Yes, IE is merely displaying the friendly error because the web application has return a status code of 404. IE thinks that means that the page was not found and thus you see the friendly error. Buddy/Wordpress, however, seems to return a 404 despite properly
finding a target. Not sure if this is by design or not.
Jan 28, 2011 04:03 PM|LINK
Jan 29, 2011 07:01 PM|LINK
Jan 30, 2011 02:56 PM|LINK
I see you've already found a solution, but in case anyone else has this problem, here are two fixes:
Jan 30, 2011 03:19 PM|LINK