Object Cache Pro


If WordPress seems out of date, or should the “White Screen of Death” ever occur, the first action is always to flush the cache. You can do that easily with the wp cache flush CLI command or through the dashboard widget.

If the flushing the cache doesn’t resolve the issue you’re experiencing; you can quickly disable the entire object cache.

Either set the WP_REDIS_DISABLED environment variable to any non-empty value, such as 1 or yes.

Or alternatively, use the WP_REDIS_DISABLED kill switch constant in you wp-config.php:

define('WP_REDIS_DISABLED', true);

Modes #

Object Cache Pro has a silent mode (default) and a debug mode.

Silent mode #

In silent mode, all errors that occur during the object cache instantiation are logged to stderr using PHP’s error_log() function, and if the instantiation or connection to Redis fails, it falls back to the in-memory ArrayObjectCache, and Redis will not be used.

If the connection to Redis was established, but a Redis command fails, the error is logged to stderr and the appropriate API value is returned, for example false for wp_cache_get().

In silent mode, only emergency, alert, critical and error log levels are logged. To log other levels such as warning, see the log_levels configuration option.

Debug mode #

The debug mode can be enabled by setting the WP_DEBUG to true, or via the debug configuration option:

define('WP_DEBUG', true);

define('WP_REDIS_CONFIG', [
'debug' => true,

In debug mode, all errors and Redis failures will throw exceptions. Those exceptions will be instances of Object Cache Pro’s RedisCachePro\Exceptions\RedisException.

Debugging with Debug Bar #

Object Cache Pro integrates tightly with the Debug Bar plugin. Make sure the plugin is installed, activated, and you’re logged into WordPress. To open it up, click on “Debug > Object Cache” in your admin bar.

You’ll see cache hits, misses, and size for the current request, as well as details about accessed cache groups.

Additionally, if WP_DEBUG or SAVEQUERIES is enabled, you’ll also see all log entries, including executed Redis commands and who performed them.

See Diagnostics for more information.

Debugging with Loggers #

Debugging cache issues is a breeze using the logging module.

Sometimes finding the issue is as easy as opening up Debug Bar and looking at what’s going on for that request, but often it’s not.

Let’s walk through a real-world scenario.

Acme Corp. was using Redis Object Cache, but sometimes getting shipping rates for international packages would not work. They managed to narrow it down to an empty array being stored in Redis when it should have been shipping rates, however sometimes, an empty array was the correct value since shipping to that country wasn’t supported.

Now the task was finding out who the culprit was since several shipping plugins could have caused it.

They set up Redis Cache Pro and a custom logger to reduce the number of log entries, since they had millions of Redis operations each hour, and a horizontally scaled infrastructure with a dozen web servers.

class AcmeShippingLogger extends \RedisCachePro\Loggers\Logger
public function log($level, $message, array $context = [])
// only log commands starting with `SET`, like `SETEX` and similar
if (stripos($context['command'], 'set') === 0) {

// only log commands for keys called `shipping-rates`
if (stripos($context['parameters'][0], ':shipping-rates') === false) {

// lookup and store who’s called the command as context
$context['backtrace'] = \wp_debug_backtrace_summary(__CLASS__);

// store the log entry in memory
$this->messages[] = [
'level' => $level,
'message' => $message,
'context' => $context,

// store all messages at once in logging instance,
// including log level, message, context and backtrace
public function __destruct()
if (empty($this->messages)) {

try {
$redis = new \Redis;
$redis->connect('', 6379);
$redis->rPush('objectcache:logs', ...array_map('json_encode', $this->messages));
} catch (\Exception $e) {