WordPress White Screen of Death – HaHaHa!

The WordPress white screen of death, otherwise known as a WSOD — can toss any WordPress admin an adrenalin high. The first thought that always enters my brain is have I been hacked? Before I even attempt to begin troubleshooting – I head to cPanel. I always  look at memory usage; last login IP; .htaccess, and the logs first. I’ve had two major WordPress hacks in the past and I do not take any chances on screwing around with plugins, themes, or anything else that may be creating that damnable WSOD – until I have verified that I have not been hacked. Yes, I’m always paranoid about the possibility…

WordPress White Screen of Death: Ping Me

WordPress white screen of death

Every time I hit upon another WSOD (I’ve had an ample amount over the years), I can hear Pink Floyd’s (Dark Side of the Moon) Brain Damage tune playing in the back of my head. “I can’t think of anything to say except… I think it’s marvelous! HaHaHa!”  Anyway, that’s my gig, not yours. There are many reasons why you could experience a WSOD:

  1. Hacked website
  2. Exhausted memory limit/connectivity time out 
  3. Failed auto-upgrade/WordPress bug
  4. Blank line at the close of  your functions.php file or at the beginning/close of your wp-config.php
  5. Broken theme
  6. Incompatible plugin(s)
  7. Security plugin related to specific user account

A Little History

I’ve been working with WordPress since its birth. I’ve loved it, coddled it, screamed at it, hated it, and sometimes even cried over it. When it is working correctly it is a sweet CMS. When something breaks and a few hours of troubleshooting turns into a few days of troubleshooting — it’s an expletive deleted CMS. When it comes to WordPress, I can fix just about anything that goes wrong with it, that is, until something odd that I have not dealt with before strolls in.

During this last oddity (with the most recent WSOD) — it threw me for a loop for almost 48 hours. I was not a happy camper and I battered poor Matt Mullenweg’s CMS with voodoo curses that can’t be repeated at this blog. I could lose clients.

Take One-Step-At-A-Time

Working on a WordPress white screen of death issue is easier to manage if you take a one-step-at-a-time approach during the initial troubleshooting process. Once you have a hint of what may have created the WSOD problem — you can map out a strategy to attack the problem head-on. I’ve known WordPress admins who just say screw it. They burn it, wipe it, and restore a back-up. I’m not that type of admin (though I’ve done it on rare occasions) — Instead, I tend to beat it up until it behaves.

Of course, I was working under the assumption that I could sequentially follow the first six steps above (as I always did in the past) and was not aware, until much later in the game that step seven was the culprit.

It Feels Like Eons Ago Now

There was a time in my life that I worked the networking department at a local University. That was also during a period of time when my troubleshooting skills was indispensable to the operation of the campus network. I created all of their campus images, scripts, etc for all campus computer and departmental labs (along with specialized software installations and the works) . When problems arose — they knew that they could count on me to resolve any image-related or networking issue. Wind the clock forward — some things never change. I am still passionate about troubleshooting.


I did not work 48 hours straight on this problem. I am not insane. The troubleshooting process involved a window of 48 hours of time when I worked on-and-off on potential solutions to my WordPress white screen of death brouhaha. My hacker friend, who exists on the other side of the pond was involved in his own little laughter fest over my dilemma.

I gave him access to read my blog drafts a few years back (there are many) – and the one that I could never publish has since been trashed. It detailed every aspect of this gals horrific troubleshooting experience replete with every non-expletive deleted word — where my friend from across the pond could have held my blog hostage for ransom.


The painful WSOD process began with cPanel and ended with a chance encounter. Curious yet? Keep reading…

So, I thoroughly checked to assure myself that my site had not been compromised. I did not exhaust memory, nor did I have any connectivity problems. I did not experience any failed auto-upgrade errors or any WordPress bugs. I double-checked my functions.php and wp-config.php for blank lines too. Next on the list was to use the default theme and since I am command-line-driven, my preference was to execute a query via PhpMyAdmin. I did not have a theme problem — so next on the agenda I set debug to true in wp-config.php.

PHP debug mode

Debug Mode Caching Errors

I began to see W3 Total Cache errors, so I thought the fix would be a piece of cake. Unfortunately, it was far from a quick fix! After renaming my plugin folder numerous times via FTP — logging into the admin dashboard, and reactivating plugins in batches, I was still at a loss for a solution.

Due to php caching errors, I decided to completely remove the W3 plugin. Removal led to more problems because I also have a CDN. I quickly rushed off some support emails to MaxCDN exclaiming how horrible W3 was behaving and that I would never use that plugin again. Next, I switched to WP Super Cache (WPSC) — and WPSC soon elevated my troubleshooting endeavors into nightmare mode. I finally managed to create (what appeared to be) a never-ending cycle of caching problems.

Wordpress Cache Errors

Exploding Manhole Covers

Decades ago (when my kids were little), I had a neighbor — who eventually turned into a stalker (after my divorce). One of his specialties was creating bombs to blow up neighborhood manhole covers. BTW, I was beyond petrified of this guy. At the time, I had little kids and a lackadaisical husband. So, when the Feds came door-to-door to ask about the bombs, I KNEW ABSOLUTELY NOTHING.

During  the interim of the WSOD troubleshooting phase, where I believed that caching had to be the problem — it was actually an exploding manhole cover. The reality is: I KNEW ABSOLUTELY NOTHING. Why? Because, I was silently seeking a solution to a problem that I already assumed that I knew the potential answer to. I was oh so wrong! Though most of the obvious php errors pointed to a caching problem — the WordPress white screen of death HaHaHa was actually due to a user problem.

PssstYou Speak In Tongues?

No. Not yet anyway. But, having concentrated so hard on what was known — I failed to consider what was unknown. Though I tried logging in with different browsers, different computers, and different devices — they all produced the same results. I failed to think outside-the-box. Sometimes we can get so caught up in seeking a quick & dirty solution to a problem that we forget to get creative during this process.

A Windows Solution?

I changed my mode of thinking. I began to think of Microsoft Windows. Of rights and permissions. Roaming profiles and policies. Firewalls and users. I also began to think that this could be related to a security plugin and potentially unrelated to any of the php debugging errors that I was currently experiencing. I began looking through the security that I had in place for the blog, as well as user accounts — during this entire process of troubleshooting, I had only logged in with an administrative account.

I wondered if logging in with a different, non-administrative account could possibly become my bingo. To test, I reactivated all of the plugins and WordPress once again tossed the admin account out of the CMS hello white screen of death, so we meet once again…

Next, I logged in with a WordPress editor account (that I rarely use) and had a pleasant conversation with the dashboard! I was in. Next, I ftp’d to my webserver and disabled all security plugins. While looking through Wordfence security settings I noted that there was a warning to downgrade my current Premium active API Key to a Free Key. My original subscription had cellphone sign-in for the admin account. Wordfence would text me a code every time that I signed into my blog and would  redirect me to sign in again and include the code that Wordfence texted me. Double Bingo! This was my problem all along. Since the editor account was not tied into a cellphone login —  it was not subject to the redirected login.

My Dads Name Was Bliss

Sometimes the simplicity of it all can become total bliss. I would never have wasted two days of troubleshooting had I been leaning more toward looking at what I had in place for security. Was it worth it? Yes it was. Though I came very close to a screw it,  burn it, wipe it, and restore a back-up — I beat up that WordPress White Screen of Death – HaHaHa!


Leave a reply