Using the WordPress Object Cache

I’ve been planning to write up a plugin to serve as an example of using the WordPress Object Cache, but haven’t had time to finish it up. However, this topic came up on the wp-hackers mailing list recently, so I thought that I would go ahead and give a brief rundown on how to use the cache from within your own plugins.

The goal of the WordPress Object Cache is to provide a way to persistently store results from expensive queries in an external cache file. This lets us avoid re-querying the database or re-fetching information from an external web service if we think that the data hasn’t changed. It should be noted, however, that some server environments have trouble using the cache. It is up to you to monitor your server to determine whether use of the cache will benefit your sites,

Using the object cache is actually quite simple. You write data to the cache using wp_cache_set(), and you read cached data with wp_cache_get().

Before I get to the sample code, there are some other things you’ll need to check. The object cache is disabled by default. In order to enable it, you’ll need to edit your wp-config.php file. Add the following lines, after the setting for WP_LANG:

// Enable the WordPress Object Cache:
define(ENABLE_CACHE, true);

Also, make sure that there is not a define for a DISABLE_CACHE constant. In addition, you will need to make sure that you have a wp-content/cache subdirectory on your host, and that it is writable by your web server process. I assume that if you are planning to write code to use the object cache, that you know how to handle this on your host server.

That said, let’s take a look at how you use the wp_cache_get() and wp_cache_set() functions in your own code. First, we'll examine how we put data into the cache. Think of the cache as a set of containers, each of which can store several data packets. You can name the containers and the packets within, so that you know how to retrieve them later. In these examples, I am naming the container mycache, and we'll call the data packet mysettings. It would probably be a good convention to name your own container based on the name of your plugin, and name the packets based on what kind of information you are storing (e.g. userdata or popularpostinfo).

Here's how we write data to the cache:

  // Whenever we need to rewrite the cache data:
  // This could be calling a database, webservice, etc.
  $mydata = my_complicated_data_query();
  $myexpire = 60 * 60 * 24; // Cache data for one day (86400 seconds)
  wp_cache_set('mysettings', $mydata, 'mycache', $myexpire);

You'll have to determine the best point in your code to do this depending on what kind of data you're caching. For example, if you are caching user profile data, you might want to update the cache anytime a user's profile changes by hooking into the profile_update() API hook.

Now, when you want to avoid that complicated database query, check the cache first. If your information is not already in the cache, or if it has expired, wp_cache_get() will return false. In that case, you'll need to re-query the database for the information. Otherwise, it will return whatever data structure that you previously stored.

  // First of all, before you try to access the user data, check
  // the cache.
  $mydata = wp_cache_get('mysettings', 'mycache');

  if (false === $mydata) {
    // The cache data doesn't exist or it's expired.
    // Do whatever we need to populate $mydata from the
    // database normally... 

    $mydata = my_complicated_data_query();

    // Since we know that the cache isn't up to date, we should
    // write this fresh information to it now, so that we can avoid
    // the query next time.
    $myexpire = 60 * 60 * 24; // Cache data for one day (86400 seconds)
    wp_cache_set('mysettings', $mydata, 'mycache', $myexpire);
  }

It's up to you to decide an appropriate amount of time to cache your data and to determine which API action hooks should trigger cache updates. A whole day will be too long for some types of information. But with this basic information in hand, it should be relatively easy for plugin authors to take advantage of the object cache.

Related posts:

1. XCache Object Cache Plugin for WordPress 2.5+
   "[drain file 16 show default_show] This is another one of those articles that will be of interest to a minority of WordPress users. In particular,..."
2. WP-Cache fix for Content-Type in feeds
   " If you run a busy WordPress site, or even if your site just has a lot of processor-intensive plugins, then you probably already run..."
3. W3 Total Cache Plugin
   " There’s a new WordPress cache plugin in town, and it’s called W3 Total Cache. This plugin is one of the contestants in the 2009..."
4. My Favorite WordPress Plugins
   " One of the coolest things about WordPress is the powerful Plugin API which allows us to create add-ons which can radically extend the basic..."
5. Text Filter Suite Plugin for WordPress
   "Since Talk Like a Pirate Day is only three weeks away, I spent some time this weekend revamping my old Fun Filters hack. The result..."