Decorative Flower
Her Realm, Personal website and blog of Cole
Feb 07

How to Fix the WordPress “White Screen of Death”

I was experiencing some issues with both blogs when I tried to install Jetpack after moving to my new host. Essentially, I would install and activate the plugins, and my dashboard would go white. The blog would work fine, but I couldn’t do anything.

A quick Google search showed that this seems to be pretty common for other users, and I pinpointed my host as an issue because another blog on another host doesn’t have this issue. However, none of the information was all in one place, so it still took me a little while to figure out what the issue was.

Per the Codex and several forum threads, I tried to rename the plugins folder (“plugins.hold”) to reset all plugins. I refreshed the plugins page and my dashboard was back, but white screen would return when I tried to activate Jetpack. The first helpful tip I found was to edit config.php to turn on PHP debugging. To do this, follow these steps

  1. Log in to your website via PHP or browser-based control panel.
  2. Open “config.php” in your root or WordPress folder in your code editor.
  3. Locate the following line
    define('WP_DEBUG', false);
  4. Change “false” to “true.”
  5. Save the file and reupload.

When you return to your white screen, you will now see an error.  The error that I found and had suspected all along was one of “allowed memory size exhausted.” Essentially. Jetpack was causing WordPress to use more memory than my host generally allows for scripts. However, you can fix this.

  1. Log in to your website via PHP or browser-based control panel.
  2. Open “config.php” in your root or WordPress folder in your code editor.
  3. Add the following line
define('WP_MEMORY_LIMIT', '64M');

When you save and upload, you can now use Jetpack and see your dashboard. This line instructs your server to allow the script to use more memory for PHP.

Remember to edit config.php to turn off PHP debugging. Otherwise, you’ll see some annoying errors in your dashboard.

It can also fix issues with other memory-intensive plugins. I frequently find that related post plugins use a lot of memory, and that can lead to errors. Other plugins known to cause issues include UpdraftPlus, and I’m pretty sure this is the reason that my backup plugin stopped working. However, the WordPress support forum is full of users who have experienced the issue with pretty bare installations, and the perpetrator seems to be the instal itself.

If this method doesn’t work, there are a few other to try. For example, add this to your .htaccess file:

php_value memory_limit 64M

Or, change the memory limit in your PHP.ini file to

memory_limit = 64M ;

Jul 08

Spicing Up the WordPress 404

The old WordPress 404 wasn’t any help. I used a fantastic plugin, Smart404, that no longer exists. Thew new one, for whatever reason, shows recent pages, with no regards to relevance or pages. How useless! What’s a girl woman to do? She spruces up her own 404, of course.

The first thing I wanted to do was to show the URL that the visitor intended to go to. To test, I had to come up with a URL that wouldn’t redirect. WordPress will try to match up broken URLs to existing page and post titles, which already takes care a lot of broken pages. A complex URL such as “” shows my 404. WordPress tags themselves won’t show you the intended address, because WordPress registers you are being on the 404 page, so I had to use a little basic PHP to show the URL:

 php $url="http://".$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI']; echo $url; ? 

I inserted this inside some friendly text, so my 404s say “It looks like you were looking for [URL].

Next, I wanted to suggest related pages. My now-defunct plug-in was so good at this, and I spend a couple hours looking for a substitute that would essentially turn the URL of the broken link into search keywords. Nothing exists. If you make this plugin, email me and I will reward you well!

Instead, I opted for the next best thing: related posts. The problem is, most related posts plugins look at only the page content, tags or categories, none of which exist for a broken link. So, I decided to simply do some trial and error, to see which plugins would get me the closest and work on the 404 page. I wound up replacing my existing related posts plugin for the blog, too, because who needs more than one? I settled on nRelate, because it seems to do the best job comparing URLs to keyword in posts that actually exist.

I inserted the code into my 404.php theme file like this:

 php if (function_exists('nrelate_related')) nrelate_related(); ?

But I wasn’t done. The last thing that I wanted to enable my visitors to do was to contact me, which was really only duplicating the report an error page that I already have. It’s kind of out of the way, so I figured that some users might be more likely to use it on the actual 404. However, I expect few people to do this. As a webmaster, we have ways to check errors and broken links, this just provides me with a little more information.

I use Contact Form 7, which has both PHP and an in-post shortcode. Because I was editing my 404 page, I needed to use the former, so I added this last chunk to my 404 page.

 php echo do_shortcode( '

' ); ?

The shortcode actually breaks it in this tutorial. Oops, but you can see where I went.

So, now my 404s show the visitor the name of the link and some possibly related entries. If none of those are good, they can at least see the link to use the search bar, which appears on every page. If this is all my fault, because I’m a horrible person, my visitors can let me know via the form. In my opinion, this tutorial makes a much more complete 404 than any default WordPress has ever used.

Psst, I have more tutorials here.

Nov 14

One small step for man; a slightly bigger step for Cole

I just figured out a way to assign my dynamic sidebars for each section a little better/easier/simpler than how I was doing it before. I was also able to delete 4 or so template files. All in all? Not a miracle or anything but it took a little experimentation and I’m quite proud!

Essentially, instead of calling one sidebar in all places, I ask it to call a sidebar for a page and all its children like so:


if ( is_page(‘pagename’) || $post->post_parent == ‘parentid’) {


} elseif (is_page(‘page2name’) || $post->post_parent == ‘parent2id’) {


} else {



Skip to toolbar