I am running into an issue where every time I create a new site on the Network(and it happened when I did the original 5-minute install of WordPress as well), I receive a 500 Internal Server Error when WordPress starts to refresh the page.
How did you fix this on your original install, then?
Well, I didn’t *fix* in on the original install. When I did the original install, it kicked to the 500 Internal Server Error page. When I went back to try to re-install it or figure out what was wrong, I discovered that everything was installed as it should be and the admin section was operating perfectly.
What flavor of PHP are you using?
PHP Version 5.3.20 w/ Apache on Cloud Linux and MySQL 5.1.66
All that’s normal… Does the page work on a refresh?
So, if I go and add a new site to the network, I get the 500 error. If I refresh the page, the page loads and WordPress gives me an error because “Sorry, that site already exists!”.
Okay… That means it’s running, but you see the 500. Uh. Do you have mod_security enabled and, if so, how strict is it?
My host’s response to the mod_security question was:
If it was mod security you would be getting a 403 forbidden message, and it is installed for your protection.
Which means to me that it is installed, but no idea what the setting is at.
I re-created the issue for them and after looking in the logs this was their response:
[Sat Jan 19 08:15:50 2013] [error] [client 68.151.36.45] malformed header from script. Bad header=/var/www/vhtdocs/userweb1/dead: site-new.php, referer: http://kether-interactive.ca/wp-admin/network/site-new.php
Are you using in wordpress a nocache option enabled?
In the wp-includes/functions.php at line 928 is the code below which looks like what you are getting above where “/var/www/vhtdocs/userweb1/dead” is the $name and “site-new.php” is the $field_value. I think this is what is outputting this funky header to apache and then apache doesnt like it and gives a 500 error.
@header(“{$name}: {$field_value}”);
I’m not exactly sure how to respond to this because it seems to me that if this was actually an issue with WordPress Multisite it would’ve been found months or years ago when the very first install procedures were tested… I just don’t know Apache or the tech side of WordPress enough to figure out why Apache is having an issue with the headers being sent. And in particular because the very first time I installed WordPress from a straight vanilla brand new download of 3.5, I was having the issue, I don’t see this being a WordPress thing as much as a random server config setting of some sort.
Are you using in wordpress a nocache option enabled?
I don’t even know what that means… o.O Do they mean did you set PHP to nocache?
I think so? Or maybe if I’m using W3 Total Cache or a similar caching plugin, none of which I’ve begun to install and tweak yet. I’m going to respond to them and see what they say.
Thanks for keeping up with this and hopefully I’ll be able to have you something more concrete to work with soon.
FWIW, you can make mod_security more friendly with WP (and in some cases, it can be a little too aggressive, which is why I brought it up). Turning it off is rarely a good idea, but that wasn’t what you had asked your host, and silly them 🙂
If it was mod security you would be getting a 403 forbidden message, and it is installed for your protection.
See … that’s mostly true. I’ve seen Mod Security do some wonderfully moronic things, where it kicked me back to the front page every time I tried to save if I had the word ‘from’ in my posts.
So, they disabled mod_security completely and it was still throwing the 500 error, so that wasn’t the problem. Their response afterwards was this:
—
As we stated before in a few ticket posts back.
In the wp-includes/functions.php at line 928 is the code below which looks like what you are getting above where “/var/www/vhtdocs/userweb1/dead” is the $name and “site-new.php” is the $field_value. I think this is what is outputting this funky header to apache and then apache doesnt like it and gives a 500 error.
@header(“{$name}: {$field_value}”);
If you want, you can remeve this code and see if that fixes it, if it does its something in wordpress and not the server, which is our guess as that is what it is. These values in the list are pulled from either code or the database and its putting them into the HTTP header causing apache to complain.
—
To me, removing the @header doesn’t seem to make sense since this issue should have shown up on one of the other 60 million odd installations of WordPress and I can’t seem to find anything else on this issue.
Coming back after 20 minutes of deeper searching, I just found out that the server is running PHP in CGI mode, so I’m getting them to adjust the server settings to the Apache handler instead based on this thread.
Horse hockey to them. Sorry, but if THAT was the case, many more people would be screaming. You didn’t edit core so I have a very very very hard time believing WordPress core to be the error. 😉 The odds are against them here.
CGI PHP would be surprising, but not outside the realm of possibility.
That was my thoughts exactly.
Their response:
—
Due to the server configuration there is no way to change it to the apache php module. If we didnt you wont have any page load, it would be 500 errors no matter what page you went to. Also I think its more along the lines of a wordpress issue, since cPanel uses php in CGI mode for security, and there are more cPanel servers running the wordpress installs running, which you can see here:
http://supportcenter.verio.com/KB/questions.php?questionid=316
“Default PHP mode: Since SuPHP is used by default, PHP runs in CGI mode. “
This is why I asked to remove the code in the file since this then takes out the equation that its the server. If taking it out works then we know its the code and not the server that is the issue, since we run this exact server setup across all of our shared hosting servers (running PHP in CGI mode) and wordpress without issue.
—
Their logic doesn’t seem to necessarily make sense to me, but interested to hear your thoughts… just going to go ahead and try it to see if it makes a difference or not.
