I’m guessing that most of you out there are familiar with the Windows Blue Screen of Death (or BSOD). However, you may be less familiar with the WordPress White Screen of Death (or WSOD), although if you’ve visited this site recently, it’s entirely possible you may have experienced one in the wild. This place has been having some issues – some that I’ve only just become aware of.
A WSOD is exactly what it sounds like – even more so than a BSOD – in that it’s a completely blank page with nothing remotely helpful on it. I first encountered one on the Burnham Book Festival site a month or so ago, when a user reported being unable to use the online shop. I did what any developer would do and googled for an answer and basically what turned up was that there were several reasons for this happening – the most likely ones being a rogue plugin or insufficient memory.
I didn’t fancy going through the process of deactivating all the plugins and then turning them back on, one by one – especially as the problem was intermittent. So I went straight for the insufficient memory explanation. And it did look plausible, because when I added the following lines to my wp-config.php to get some debug output:
define ('WP_DEBUG', true);
define ('WP_DEBUG_LOG', true);and looked at the debug.log file generated in my wp-content folder, it reported that at some point – which varied from one instance to the next – it was trying to get more memory than a pre-defined limit. This limit looked suspiciously like 128Mb.
So I added the requisite line below this to double the memory to 256Mb:
define('WP_MEMORY_LIMIT', '256M')However, this had the effect of stopping the site from working altogether. I made the hasty assumption that there was some kind of limit imposed by the hosting provider, and reverted the change. Instead, I googled the names of one or two of the plugins that weren’t actually being used and found one that someone was complaining was using too much memory. I deactivated that and everything seemed to be working again.
Which was all fine until I took another look today, and of course the site had stopped working again. It had fooled me into thinking I’d fixed it. Whilst I was at it, I thought I’d take a look at this place as well and, lo and behold, this one wasn’t working either. Hmmm. Time to get the thing fixed properly.
The problem I’d had with the excess memory report was that it identified the amount of memory being requested and the piece of code that was requesting it. However, the amount being requested was only the straw that broke the camel’s back. Somewhere there had to be a rogue plugin that had been activated earlier on and was grabbing more than its due. So I opened up the site’s wp-settings.php and located the point where the various plugins were being activated and added a couple of lines of PHP code to output the current memory usage to the debug.log file.
Unfortunately, all that this revealed was that pretty much all the plugins were grabbing loads of memory and there wasn’t one that could be identified as the sole culprit. This wasn’t very helpful. So I thought, well maybe this site has different rules regarding increasing memory limits. So I went back to wp-config.php and added the crucial line again:
define('WP_MEMORY_LIMIT', '256M');This time, it worked a treat. So what was the difference between my site and Burnham Book Festival? Eagle-eyed readers may have spotted it already. It’s that semi-colon delimiter at the end of the line. Call yourself a programmer, Pinnock? I’ve used C/C++ for most of my life, but somehow I managed to get sloppy when it came to PHP. I blame messing about with Python and Swift in recent months. So I added the semi-colon in to the Burnham Book Festival instance of wp-config.php and amazingly that started working too.
Anyway, basically what I’m saying is that the easiest fix for the WSOD is to add that line to your wp-config.php to increase the memory limit. But whatever you do, don’t forget the semi-colon.