08.07.08
Solution to Wordpress Blank Screen of Death
As I posted last week, getting my blog hacked forced a wordpress upgrade to v2.5.1 however it also caused a problem I had previously been unaware of, the Wordpress Blank Screen of Death. This is basically where under some circumstances, you get a blank plain white screen instead of the page you were looking for. In my case, I was completely locked out of the admin screens and could do nothing with the blog apart from post comments!
This post is going to take you on a journey, one that starts with following standard debugging techniques that I’ve learned from years of experience in the IT industry and ends in a discovery so surprising, it’s made me question the fundamental quality of the whole blogging phenomena that is Wordpress (Wordpress is the blogging software this crossfit blog uses and is arguably one of the most popular). I started off as anyone should when faced with a new and unfamiliar problem, by doing some research:
What I found was that this appears to be a common Wordpress problem suffered by many bloggers and can arise in many possible situations e.g.:
- After writing a comment and clicking Submit.
- Accessing any of the main blog screens.
- Accessing any of the administrator screens.
- After *doing* something in the administrator screens.
During the upgrade, I noticed I was suffering from (4) above. I could access the admin pages no problem, but whenever I tried to do anything adminy I’d get the Blank Screen of Death e.g. change a plugin setting or write a post or change anything. The action I was performing worked ok, but I’d have to hit the back button and do an F5 Refresh to see the results of it. At the time I figured I’d deal with it later.
It was made worse because there were no error messages: No errors on the wordpress white screen of course; nothing in the main wordpress error.log; nothing in the plugin error log; and nothing in the webserver apache error log. And in the absence of any information it’s a tough problem to debug. However, with my advanced level Google Foo, I was pretty confident of finding the answer. I did in the end, but it took me hours!
Here are all the causes and working solutions I found on the net that others have specified:
- A partially complete upgrade – Solution: Re-upload the upgrade files.
- FTP Client making a mess of the upgrade – Solution: Get a better FTP client and re-upload the upgrade files.
- Something failed running /wp-admin/upgrade.php upgrade script – Solution: Find out what failed (check logs), fix it and re-upgrade.
- Incompatible Plugin Enabled – Solution: Disable all plugins, then add them back one at a time to see which one causes the problem.
- Adding the new define(‘SECRET_KEY’,… parameter into wp-config.php – Solution: Don’t put it at the end of your file, put it before the line that says /* That’s all, stop editing! Happy blogging. */
Working down this list posed a problem: How could I disable the plugins without access to the admin screens?!? In the end I had to manually hack the MySQL database directly via the back end. In short, here’s what I did:
- Accessed my webserver admin screens, cPanel in this case.
- Accessed the phpMyAdmin MySQL user interface.
- Browse the wp_options table.
- Find the field called: active_plugins.
- If you just want to look without the risk of cocking it up, here’s the SQL you need:
- SELECT option_value FROM wp_options WHERE option_name = ‘active_plugins’ LIMIT 1;
- First things first before you go fiddling: BACK UP THE VALUE OF THIS FIELD by copying to a text file on your PC.
- Then either us phpMyAdmin to blank the value of the active_plugins field, or use this SQL:
- UPDATE wp_options SET option_value = ” WHERE option_name = ‘active_plugins’;
- Just to be clear here, if you don’t know what you’re doing, then don’t do it! I’m not responsible for you messing up your blog even more. You should have regular backups and have proven to yourself that they work and you are competent enough to restore from those backups.
Anyway, that will disable all your plugins… great. Just one problem: it didn’t fix my Blank Screen problem!
I’ll cut a long story short, as it did take me another hour or 2 to finally find the solution. Now what I’m about to say is a complete shocker to me. As an experienced IT person, someone who has been messing around with and programming computers and working on IT projects in every possible role up to IT Director for over a decade, I am completely dumb founded by what I’m about to describe, because how the human race has got to 2008 with all the technologically related advances we have made, and yet still introduce a hugely powerful and popular program like WordPress, that is brought to it’s knees by the most innocuous of things… it’s just completely beyond me.
Anyway here is the answer: it lies in the wp-config.php file, this is the file where you set your database password etc (so you’ll forgive me for not using my own real one. 
). This is the example file that comes with the installation:
— File Starts —
<?php
// ** MySQL settings ** //
define(‘DB_NAME’, ‘putyourdbnamehere’); // The name of the database
define(‘DB_USER’, ‘usernamehere’); // Your MySQL username
define(‘DB_PASSWORD’, ‘yourpasswordhere’); // …and password
define(‘DB_HOST’, ‘localhost’); // 99% chance you won’t need to change this value
define(‘DB_CHARSET’, ‘utf8′);
define(‘DB_COLLATE’, ”);// Change SECRET_KEY to a unique phrase. You won’t have to remember it later,
// so make it long and complicated. You can visit http://api.wordpress.org/secret-key/1.0/
// to get a secret key generated for you, or just make something up.
define(‘SECRET_KEY’, ‘put your unique phrase here’); // Change this to a unique phrase.// You can have multiple installations in one database if you give each a unique prefix
$table_prefix = ‘wp_’; // Only numbers, letters, and underscores please!// Change this to localize WordPress. A corresponding MO file for the
// chosen language must be installed to wp-content/languages.
// For example, install de.mo to wp-content/languages and set WPLANG to ‘de’
// to enable German language support.
define (‘WPLANG’, ”);/* That’s all, stop editing! Happy blogging. */
define(‘ABSPATH’, dirname(__FILE__).’/');
require_once(ABSPATH.’wp-settings.php’);
?>
— File Ends —
That is a perfectly fine, normal and working wp-config.php. Now I’m going to show you a broken one. One so terribly horrendously broken, that it causes you to be locked out of your workdpress blog for half a week and lose 1/2 a day trying to solve it. See if you can spot the difference:
— File Starts —
<?php
// ** MySQL settings ** //
define(‘DB_NAME’, ‘putyourdbnamehere’); // The name of the database
define(‘DB_USER’, ‘usernamehere’); // Your MySQL username
define(‘DB_PASSWORD’, ‘yourpasswordhere’); // …and password
define(‘DB_HOST’, ‘localhost’); // 99% chance you won’t need to change this value
define(‘DB_CHARSET’, ‘utf8′);
define(‘DB_COLLATE’, ”);// Change SECRET_KEY to a unique phrase. You won’t have to remember it later,
// so make it long and complicated. You can visit http://api.wordpress.org/secret-key/1.0/
// to get a secret key generated for you, or just make something up.
define(‘SECRET_KEY’, ‘put your unique phrase here’); // Change this to a unique phrase.// You can have multiple installations in one database if you give each a unique prefix
$table_prefix = ‘wp_’; // Only numbers, letters, and underscores please!// Change this to localize WordPress. A corresponding MO file for the
// chosen language must be installed to wp-content/languages.
// For example, install de.mo to wp-content/languages and set WPLANG to ‘de’
// to enable German language support.
define (‘WPLANG’, ”);/* That’s all, stop editing! Happy blogging. */
define(‘ABSPATH’, dirname(__FILE__).’/');
require_once(ABSPATH.’wp-settings.php’);
?>— File Ends —
What do you think, can you see it the mistake that breaks the whole blog? No? Go back and look closely…
Still no? Ok ok, I’ll give it to you, here’s the problem:
What? You can’t see that either? Let me show it to you again, look carefully this time:
You getting it yet? Yep, it’s an empty line. That’s all it is. 1 single solitary NewLine at the bottom off the file, right after that ?> a Carriage Return & Line Feed in programmers speak. That’s it. You hit the Enter key in one wrong place and the whole pack of cards comes tumbling down! Shocking, just shocking. Let me be crystal clear, it’s this bit here:
?>
— File Ends —
Now of course, the Analyst in me wants to know how this happened and I’ll tell you. The issue was the the new define(‘SECRET_KEY’… entry I mentioned before. That should have been my warning, because when I was following the upgrade instructions, they don’t tell you where to put it, so naturally I first put it at the end of the file…. yep you guessed it: AFTER the ?> . I realise now of course that was stupid and it didn’t work. What was the symptom of it not working? You guessed it: the Wordpress Blank Screen of Death.
But when I moved it to the correct place, I was still sporadically getting problems, then I commented the line out and basically with all the changes I made I seemed to have got myself into the situation where I was getting the problem, but only half the time. I reckon the currently open admin session I had going was probably masking half of the issue from me. But in putting it at the end of the wp-config file and then moving it, I must have left behind an empty line. How silly of me! So just make sure you have no extraneous characters after the ?> I’d recommend checking for those evil and nefarious spaces too.
Anyway, that’s the fix and probably the most comprehensive study of getting wordpress blank screens anywhere on the net. If you find this post useful, please consider linking to this post from your blog, it will help others find this article who may have the same problem.
Cheers.
EDIT: Austin in the comments has also reported that: “This can also happen in your themes functions file. Make sure you do not have any “extra” returns after your last ?>”