Error 500 Header sent, but page still loads

I've come across a bug I can't seem to fix on a website we launched recently, running on 2.2.7-pl

The live version of the site: http://www.sfxschool.org.uk/ shows a response code of 500, but the pages still load, however things like WMT and the W3C Validator fail to recognise the site, as they see the 500 error first

Meanwhile, on the demo site, which is exactly the same in terms of the codebase behind it, just held on a different portion of the same server, I get no such error: http://sfx.madebygeo.net/

I found a bug report which describes something similar, but I'm not using the [[+modx.user]] calls which it refers to as a cause: http://tracker.modx.com/issues/7446

Anyone seen anything like this and can give me an idea of where to look for an answer?

Did you modify the site start id at all?

No, both installs use resource ID 1 for the site start

Take a look at the server log in cPanel to see if there are any clues there.

MODX very rarely puts out a 500 error and I don't know of any extras that do.

500 errors most often come from the .htaccess file, but they're usually fatal.

If did find this:

Recently I came across a web server w/o /etc/php.ini file.

=> /etc/php.ini

Many scripts open this file on fly to get correct configuration directives. If this file not found you get error 500. It took some time to figure out this problem. Finally strace helped me out to debug this problem.

Something wrong with the PHP code in a snippet or plugin most likely. Here's something from a WordPress forum...

ok, I've figured it out. There was some invalid PHP being passed to an eval() call. That PHP parser error within eval() was causing the status to be set to 500, even though execution proceeded just fine and rendered the page.

(Specifically, there was a function taking a string expression to be evaluated. It was 'sanitizing' it making it safe to execute as PHP - just restricting it to simple math expressions - then passing it to eval wrapped in "return ($expr);". Problem was it wasn't considering when $expr was the empty string and since "return ();" isn't valid, that was causing it).

Hm. Somebody else on the ZenCart forums reports this apparent solution

As the 500 error is no longer showing within the Headers, looks like disabling "Content-Encoding: gzip" solved that problem.

Ironically, after my post above, I ran into a similar problem. Everything was fine on localhost but gave a 500 error on the remote. It turned out to be a file name that was all lowercase on the disk but mixed-case in the require_once statement -- nearly drive me crazy. Windows file names are case-insensitive so it worked fine on my local machine.

Okay, it turns out that in my case, setting the PHP display_errors parameter for that particular vhost to 'On' instead of 'Off' made the 500 error go away

Not entirely sure why, that's a matter for further investigation, but at least it's now visible to search engines!

Maybe your host has it on and you're not allowed to change it?

It should never be on in a production site because a) it's inelegant to show users PHP error messages, and b) there's the potential to show too much information about your site.

I would talk to the host about getting it turned off, unless it's a private development site.

The problem is, that's a server error, not a PHP error. You really need to find out why the server is returning that error in the HTTP header.