Preventing the Unpredictable White Screen of Death for WordPress Sites with Multiple Themes

For the past several months and up until just recently, Perishable Press had been suffering from unpredictable episodes of the dreaded white screen of death. Although blank white screens happen to virtually all WordPress users now and then, certain configurations seem to trigger crashes more frequently than others. Here, I am referring to WordPress version 2.3.

In this case, the unpredictable crashes, inconsistent errors, and general instability began several months ago after I had completed my WordPress theme restoration project. Prior to that, I had removed all of my alternate themes and placed them on a subdomain. Meanwhile, after the themes had been removed, I decided to enable the default WordPress cache (don’t ask why). For the next month or so, before restoring my themes, my site performed exquisitely: uptime at 99% (on a shared server, no less), virtually no errors, and so on. Then, after restoring alternate theme functionality, the site began locking up and crashing multiple times each day. Here is a summary of the sequence of events (estimated time frames):

• eight months ago: alternate themes available for users, but default WordPress cache disabled. No problems.
• six months ago: alternate themes removed, default WordPress cache still disabled. No problems.
• shortly thereafter during site renovation, default WordPress cache enabled. Still no problems.
• three months ago: restoration of alternate site themes with default WordPress cache still enabled. Problems begin.
• until recently: white-screen-of-death syndrome persists, daily site crashes, et al.

In my mad rush to resolve the instability, I had forgotten about enabling the WordPress cache and assumed that the problem was entirely theme-related. I began checking each theme individually, testing unusual scripts, disabling various plugins, and so on. Each of the restored themes was using a custom function.php file containing a handful of miscellaneous functions that aren’t required sitewide. After some investigation, I discovered several bits of key information:

• after making the restored themes publicly available, people were actually using them (surprise!)
• switching themes (via Ryan Boren’s Theme Switcher Plugin frequently resulted in site errors and crashes
• multiple theme switches inevitably triggered the white screen of death
• many of the blank white screen problems were involved with the “Presentation” and “Plugins” pages of the WordPress Admin area
• the instability also affected comment-form functionality

The Solution?

Of course, in retrospect, the solution is simple: disable the default WordPress cache¹. I should have heeded Ozh’s advice a long time ago. Once I finally realized the problem and disabled the cache, everything was fine: no more errors, crashes, or dreaded blank white screens of death. As simple as this may be, it should be noted that, throughout the ordeal, multiple factors were involved:

• multiple themes, each using its own functions.php file — removing various scripts from the functions.php file reduced but did not eliminate the problems
• Ryan Boren’s Theme Switcher Plugin, which enables users to skin the site with alternate themes — at one point, I considered replacing Ryan’s plugin with this newer version, but it just wasn’t a good fit. So I wrote my own theme-switch plugin!
• the WordPress default cache — there are better ways to cache your pages
• Akismet filter for eAccelerator — my host tried to stabilize performance by implementing an eAccelerator filter for Akismet

Although I am confident that the entire problem was directly related to the WordPress cache, I list these other items for the sake of others who might be dealing with the same issue.

I hope this article proves helpful to someone. If you have experienced similar issues, share them with the community, especially if you discovered alternate solutions or strategies.

Footnotes

• ¹ Recall that this article refers to WordPress version 2.3 (and previous). As of WordPress 2.5, the default file-based object cache has been removed.

About the Author

Jeff Starr = Fullstack Developer. Book Author. Teacher. Human Being.