Sometimes when Wordpress runs out of available RAM on its housing server, it can yield some pretty strange results, including blank pages, timeouts, and unexplained errors. Wordpress isn’t terribly verbose about memory related errors when they are encountered, and as such – one can spend a lot of time looking for errors in your PHP code, where none truly exist.

If Wordpress runs into its server’s memory limit whilst rendering a page, more often than not, it will simply shut down – leaving no error message or indication of what had caused the problem, simply an ominous white screen, and a couple of lines of source code.

There are a multitude of signs that your installation of Wordpress hasn’t got enough memory to function correctly:

• Partially or Fully Blank Screens.
• Admin Sections not rendering fully (reading-options.php seems to be a widespread indicator, failing to render below the first drop down box) .
• Plugin Management not rendering completely.
• Sections of the site which rely on the wp_list_pages tag not rendering fully or at all.

If your pages are rendering partially, its useful to look at the point in the source code at which Wordpress ceased rendering the page, as this can give us an indication of the process which caused the installation to tip over the limit.

In my experience, if a clent’s Wordpress installation needs to serve a lot of pages (when using Wordpress in a CMS role), the wp_list_pages tag can act as the tipping point on servers with low system memory. With enough pages, this tag can eat through aroud 15MB+ of an allowance. Couple this with a multitude of other PHP processes, and you’ll blast your way through a basic shared hosting package’s RAM very quickly.

We can quickly check what our memory limit is for operation of our scripts by creating a file with the content:

<?php phpinfo(); ?>

Name this file phpinfo.php, and upload it to your server. Visit the newly created page, and search for the term: ‘memory_limit’. This will tell you how much space your site has to do PHP calculations – if it’s in the 20MB region, you’re very likely to encounter problems with sites including larger volumes of content.

Without any explicit indication of what is causing an error on your installation of Wordpress, one can feel a bit lost – especially when with some shared hosting packages *cough*1and1*cough*, you aren’t given access to your server error logs.

As a lot of these hosts aren’t forthcoming in granting a larger slice of shared memory without a costly upgrade, it’s important to be fairly certain that memory limit is what is causing the problem, before taking the plunge and urging a client to upgrade their package. There’s a few things we can do that can implicate low memory as a core problem:

Test to see whether there is any improvement after:

• Taking Plugins Offline.
• Switching large sections of the site onto ‘Draft’ mode (i.e pages with large quantities of sub-pages).

It is worth pointing out that whilst low PHP memory can be the root of rendering problems, it can also be the case that a badly written plugin or modification to Wordpress’ core code may munch its way through vast swathes of system RAM. It’s important to make certain that any code is well formed and written, before placing blame on the package’s low memory.

When reducing Wordpress’ memory footprint, there’s a few tricks that can help us to make progress. Converting tags such as bloginfo(’template_directory’) to their hard coded counterparts can help reduce system load, and Disabling plugins which aren’t core to the operation of the site.

If you’re lucky enough to be able to up your memory limit without an account upgrade, Perishablepress has a great guide on how to go about the process, and some good advice surrounding the issue in general.

Tags: errors, PHP, Wordpress

This entry was posted on Friday, March 14th, 2008 at 3:04 pm and is filed under Wordpress Development. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.