Greg’s Plugins for WordPress

Plugins for WordPress

Blog & Announcements

Fixing WordPress 2.8 Problems: Blank Plugin Options Pages, Extremely Slow Admin Pages, and More

WordPress can be dangerous to your mental health! For all kinds of reasons, each new release of WordPress creates headaches for a subset of users. Learn how to fix a few of the commonly reported performance problems with the 2.8 update.

Photo by koka_sexton - //
Photo by koka_sexton -

NOTE: This article was originally published on the Psychology, Philosophy and Real Life blog and was later moved here to

The recent point update to 2.8 seems to have brought more than its fair share of performance problems which are directly attributable to WordPress itself and cannot be blamed on plugins, themes, or poor web hosts. If you use WordPress yourself, I hope you haven’t experienced them, but if you have, here are a few quick tips on how to overcome them.

And in case you’re wondering why I’m even writing an article like this for a mental health site, it’s because:

  1. many of you are WordPress users too, and
  2. like many other plugin authors, I am receiving requests for help with problems that have nothing to do with my plugins and everything to do with WordPress.

WordPress 2.8 Performance Tip #0: WordPress is a Performance Hog. Deal With It.

There’s no two ways about it: WordPress is full of huge swaths of code that make programmers from other environments cringe. I’m not talking about themes or plugins; I’m talking about the core code of WordPress itself. If you don’t believe that WordPress has been driven more by feature-itis than by coding elegance or efficiency, I have one really long word for you: SQL_CALC_FOUND_ROWS. For years now, WordPress has persisted in using SQL_CALC_FOUND_ROWS even though it is widely known to be grossly inefficient, resulting in database query times two time greater, three times greater — even an order of magnitude or more times greater — than easily available alternatives. That’s just one example; there are dozens, maybe even hundreds more. (See this Coding Horror article for some quantitative assessments.)

The point is that WordPress is fundamentally a performance hog, and if this were a mental health blog, I might even be inclined to say that the first step in changing is recognizing that there’s a problem. In other words, if you’re going to use WordPress at all, recognize that it generates a whole slew of performance issues all by itself, so prepare yourself for the likelihood that you will, sooner or later, have to face up to that.

Recognizing there’s a problem with WordPress performance and doing something about it also means staying skeptical about whether you really need this or that latest plugin — and for plugins you do feel you need, it means keeping them updated and staying abreast of alternatives that can do the job more efficiently. (For example, one of my own plugins does its job more efficiently than almost any of the alternatives available. See “Introducing Greg’s High Performance SEO Plugin for WordPress”.)

WordPress 2.8 Performance Tip #1: Fix the Results of a Botched Auto-Upgrade

Various failures have been reported for the built-in WordPress auto-upgrade facility, both when upgrading WordPress itself and when upgrading plugins. If you see an “upgrade failed” message in your admin panel, don’t panic! You did make a backup of your database before upgrading, right? No? Do that first before doing anything else…

Now visit the WordPress documentation site for a full guide to Upgrading WordPress. In a nutshell, you’ll just manually upload the relevant files using FTP and, in the case of a full WordPress upgrade, visit /wp-admin/upgrade.php after uploading.

In the case of a failed plugin upgrade, you’ll also upload the plugin files manually using FTP and then re-activate the plugin. (In at least one case, I have personally seen the WordPress 2.8.4 plugin upgrade routine actually delete all the files in a plugin’s directory, without adding any new ones — so if that happens to you, you won’t even have had the chance to deactivate the plugin in the first place. In that case, be sure to visit the Plugins admin page at least once before uploading the new files so that WordPress can register the fact that the plugin has disappeared.)

Bonus Tip: Consider doing only manual upgrades until fewer users report problems with the built-in WordPress upgrade facility.

WordPress 2.8 Performance Tip #2: Fix Blank Plugin Options Pages

If you’ve just updated to WordPress 2.8 and you’re now seeing blank options pages for one or more plugins, where everything worked fine before, don’t assume that it’s the plugins at fault. First check the tip above, to ensure that your WordPress installation itself is intact, as well as that the plugin files themselves are where they should be and didn’t get clobbered by a botched auto-upgrade.

Then move on to the other likely culprit: memory.

Although WordPress 2.8 is generally a little snappier all around than the previous version, the fact is that most users find that it also consumes significantly more memory. Among other problems, when WordPress runs out of memory, it can result in blank plugin options pages, especially (but not exclusively) for those plugins which avail themselves of the new plugin option handling code which debuted in WordPress 2.7.

The first thing to check if you think you may be having memory problems is to have a look to see if there’s an error_log file sitting in the top level of your WordPress installation directory. Is there one? If there is, that means WordPress has logged at least one error, so download it with your favourite FTP software and open it up. Do you see memory errors in the list? It’s entirely possible that flaky plugins could be generating memory errors or execution time errors (SK2 seems to be a big culprit, for example), but if WordPress itself is running short of memory, you’re also likely to see several core WordPress files mentioned in the log.

The solution? PHP needs more memory, and you can address that in several ways. The first stop is to open up your wp-settings.php file at the top level of your WordPress installation and change WP_MEMORY_LIMIT from 32M to 64M. (You can also add a DEFINE line for the same constant in wp-config.php.) If that doesn’t do the trick, you can also ask your web host to up your PHP RAM allocation via your php.ini file, where a line like memory_limit = 32M can be changed to memory_limit = 64M.

In most cases, upping the PHP RAM allotment to 64MB will do the trick, although if you’re also running several memory-intensive plugins, you could consider going even higher.

WordPress 2.8 Performance Tip #3: Fix Extremely Slow Admin Page Loading

I was personally hit with this problem in a big way. When ‘upgrading’ from WordPress 2.7.x to WordPress 2.8.x, my admin pages went from load times in the .5 second to 2 second range all the way up to a range of 9 seconds to 70 seconds. The admin pages became almost completely unusable.

I tried all the things listed above, like reinstalling WordPress and allocating more memory. I disabled all plugins. I checked permissions on files. I started tracking database queries in the back-end and watched DB queries go down very slightly but loading times skyrocket as I switched from 2.7 to 2.8.

So I turned to the DB tables themselves, popping into phpMyAdmin to check the tables and optimize them. No change. I started dropping junk out of the tables that had been left behind by old plugins I didn’t use anymore. No change.

Finally, a solution: delete old post revisions! I used the following SQL statement from within phpMyAdmin:

DELETE FROM wp_posts WHERE post_type = "revision";

And presto, just like that, admin page performance problems disappeared! To make sure I didn’t accumulate any more useless post revisions in the database, I also shut off revision tracking in wp-config.php by adding the following line: define('WP_POST_REVISIONS', false);.

Why on Earth would having extra post revisions in the database make any difference whatsoever to admin page loading between WordPress 2.7 and 2.8? I have no idea! But what I can tell you is this: the symptoms and the solution were the same across five different WordPress installations, on unrelated blogs on three different sites running different sets of plugins and with completely different histories. Given that I could switch back and forth between the two versions and see performance plummet immediately under 2.8, I can only conclude that something is being done with grossly lower efficiency in WordPress 2.8 when a significant number of post revisions exist in the database.

Bonus Tip: You can track your own admin page database queries using the following simply code that can be dropped into your functions.php or wrapped up as a plugin:

add_action( 'in_admin_footer', 'gdbq_admin_footer' );

function gdbq_admin_footer() {
echo get_num_queries() . ' queries in ' . timer_stop(0,3) . ' seconds<br />';

WordPress 2.8 Performance Tip #4: Recognize the Limits of Opcode Caching, Page Caching, and Server Upgrades

I enlisted the help of quite a few folks trying to solve my own recent WordPress performance problems, and almost everyone pointed out that I really ought to be using various PHP opcode caching techniques, implementing page-based caching with something like WP-Super Cache, or even upgrading the whole server to handle the load. But while each of these has its own merits, in a sense they all miss the point completely: they are all general speed-ups that fail to address the very specific WordPress performance problems I was experiencing. Throwing more power at the problem with a server upgrade or boosting PHP efficiency with opcode caching can achieve significant improvements in performance across the board, but if there is some fundamentally inefficient code underlying it all, they do not address that problem in the slightest! And of course while WP-Super Cache is nice, it obviously won’t do a thing to boost your admin page loading times (since it caches regular WP output, not admin pages).

So by all means, run your PHP as efficiently as you can on the hardware that you need, but will that solve a problem which at its root is, dare I say it, poor programming? Probably not.

UPDATE (18 August 2009): I was just reminded that some folks out there are still running PHP version 4.x rather than version 5.x. That’s one upgrade that definitely will improve how efficiently WordPress runs. Unless you’re also running some other software package that specifically requires PHP 4, there’s little excuse for not updating to PHP 5. If you’re still on PHP 4, it’s probably worth talking to your web host immediately.

The Overall WordPress Performance Picture Under 2.8

Should any of these problem stop you from upgrading to the latest version of WordPress? No, they shouldn’t — WordPress 2.8 is, in many ways, a big improvement over the previous point release. But it’s hard to rule out the possibility that you’ll be among that minority of users destined to experience major problems with the upgrade. If you are, I hope these tips might help.

4 Responses (2 Discussion Threads) to “5 Essential Tips for Overcoming WordPress 2.8 Performance Problems”

The comments form is currently closed, but you can click to read the comments left previously on “5 Essential Tips for Overcoming WordPress 2.8 Performance Problems”.