I fought the white screen, and I won!

Last Updated on January 11, 2022 by Dave Farquhar

WordPress occasionally suffers from the dreaded “white screen of death,” where you visit an admin page and, instead of being able to do what you want to do, you get a blank white screen. Meanwhile, the blog continues to function. If you have scheduled posts, they keep going. But with no admin access, the blog essentially becomes a ghost ship.

Several of the causes are pretty well documented, so I’ll talk about mine instead of rehashing old advice you can easily find elsewhere.

In my case, I reinstalled WordPress over my existing copy. I host my own blog off my own Linux box in my basement–it’s about the only operational sysadmin experience I get these days–so I have command-line access, root, and even physical access if I need it. And I used two of the three in this case.

Before I get to exactly what I did, here’s why:

  • I run Debian, for what that’s worth.
  • My WordPress blog is in /var/www because that’s where Debian puts its web content. Yours may not be, so adjust if necessary.
  • I didn’t want to overwrite my content, so I renamed wp-content because I’m paranoid. Best practice? Maybe not, but I figured I’d leave that directory alone unless this didn’t solve my issue.
  • I’m sure there are faster, more efficient ways to do this. I’m not a day-to-day sysadmin anymore so I went for familiarity, not elegance or cleverness.

Here’s what I did, blow by blow:

cd ~
wget https://wordpress.org/latest.tar.gz
mkdir wp
mv latest.tar.gz wp
cd wp
tar xvzf latest.tar.gz
cd wordpress
mv wp-content wp-content.bak
yes | cp -r * /var/www

And that brought me back to life. Had it not, I would have copied the contents of wp-content.bak into /var/www/wp-content.

If you connect to your website via FTP or other means, you could do what I did locally, then upload your local copy to your website.

Good luck. If this doesn’t fix it, other likely culprits are corrupted themes, corrupted plugins, extra blank lines at the end of wp-config.php, or insufficient PHP memory. But those are well documented elsewhere.

So what about backups? Most WordPress backup solutions require WordPress to be in a functional state first. So you may have to do this whether you have a backup from yesterday or not. And backups are really for content. Given a choice between restoring WordPress files from a pristine source or from a backup, go with the pristine files, just in case any of the files in that backup got compromised.

If you found this post informative or helpful, please share it!
%d bloggers like this: