"Some PHP errors will prevent any execution at all, including code that changes the setting."
This behavior seems to have perplexed many a WordPress administrator.
"HTML/CSS seem to be much more forgiving, whereas a single character of incorrect [PHP] seems to crash the whole site," wrote Amber Seeree, in one blog entry devoted to troubleshooting the issue.
Another developer got a white screen after inadvertently adding a single newline character to his configuration file. "You hit the Enter key in one wrong place and the whole pack of cards comes tumbling down!" wrote frustrated blogger Colin McNulty in 2008.
The WSoD can be triggered by any one of a number of issues, most all of them PHP-based, said Mark Jaquith, one of the lead developers for WordPress (Jaquith is not affiliated with Automattic).
White screens could be brought about by insufficient memory, a bungled configuration code, a problem with one of the plug-ins or themes.
Faulty plug-ins seem to be fault in many cases. And the way to find the faulty plug-in is requires some simple detective work.
Jaquith recommends renaming the "plugins" directory, which will deactivate all the plug-ins. If the site works after this, then the problem is a plug-in. At this point, the administrator can restore, one-by-one, each plug-in, until the faulty one is identified when the site crashes again.
The true aggravation of the WSoD comes not so much from any one specific error, but the lack of any immediate information about what has gone wrong. This is the way PHP handles errors, and it actually is, as the saying goes, a feature, not a bug.
PHP offers the option to display an error message on the affected page, though using this option is a bad idea for a number of different security reasons.
"The error message might reveal information about the server environment (like file paths) or information about what plug-ins are being run," Jaquith said. A Web site attacker could use such information to aid in an attack.
Writing error messages also requires granting write permission to publicly accessible files, another generally bad idea, Seeree pointed out.
Instead of having the server print the error message of the affected pages themselves, the administrator should look for the file in the system where PHP does log the errors, Jaquith advised. Most all server software will write error messages to a log file somewhere, as do most hosting systems like cPanel or Plesk.
Even though the cause of the WSoD lies outside of WordPress itself, WordPress developers are working to minimize its presence. For instance, WordPress checks for fatal PHP errors when activating a plug-in. If a fatal error occurs, the plug-in is sandboxed, meaning it is not activated until the problem is fixed.
The upcoming release of version 3.0 of WordPress will have even more measures to prevent blank screens, Jaquith said.