# Redis Object Cache, a persistent object cache for WordPress

> The Redis Object Cache plugin gives WordPress a persistent object cache backed by Redis, through Predis, PhpRedis or Relay, with TLS, ACL authentication, replication, sentinels and clustering. Its configuration surface is unusually wide, and it includes a set of switches labelled unsupported that exist precisely so a broken site can be diagnosed rather than silently corrupted.

**rhubarbgroup/redis-cache** — A persistent object cache backend for WordPress powered by Redis. Supports Predis, PhpRedis, Relay, replication, sentinels, clustering and WP-CLI.

- Repository: https://github.com/rhubarbgroup/redis-cache
- Website: https://wordpress.org/plugins/redis-cache/
- Stars: 543 · Forks: 164
- Language: PHP
- License: GPL-3.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/rhubarbgroup-redis-cache

## A drop-in for a cache that normally dies with the request

The Redis Object Cache plugin is a persistent object cache backend for WordPress powered by Redis, and the plugin page is at wordpress.org/plugins/redis-cache.

The problem it solves is that WordPress's own object cache is per-request. Every key your code puts into the cache lives in PHP memory and is gone when the request ends, so the same option lookup, the same post metadata query and the same term query happen again on the next request. On a busy site that is a lot of repeated work, and it is work that is invisible in the query log because each individual query is fast.

Installing the plugin drops a persistent object cache into WordPress, so those values are stored in Redis and survive between requests, and a second visitor benefits from the first visitor's work.

The plugin description names the components it supports, and the list is broad for a cache plugin: Predis, PhpRedis as the PECL extension, and Relay, plus replication, sentinels, clustering and WP-CLI. The homepage is the WordPress.org plugin directory listing, which means the distribution model is the WordPress plugin ecosystem rather than a Composer dependency, even though the repository has a `composer.json`.

The primary language is PHP, the licence is GPL-3.0, and the default branch is `develop`, which is worth noting because it tells you the released code and the branch you would clone are not necessarily the same thing. The recorded releases are 3.0.0 from 2026-09-18, 2.8.0 from 2026-05-04 and 2.7.0 from 2025-09-29, and the last push to the repository was on 2026-10-07.

There is a commercial counterpart, Object Cache Pro, which the README promotes as a business class version of the same thing with a dedicated engineer, faster serialization and compression, debugging and logging, cache prefetching, advanced analytics, full unit test coverage, and optimisation for WooCommerce, Jetpack and Yoast SEO. The open plugin is what this review is about, but the split is worth knowing about, because a lot of the operational tooling you might want is in the paid version.

## Choosing the client, and what a prefix is for

The client is a configuration constant, and the default is derived from what is installed rather than being fixed.

`WP_REDIS_CLIENT` selects the client used to communicate with Redis. It defaults to `phpredis` when installed and otherwise `predis`, and it supports `phpredis`, `predis` and `relay`.

That defaulting behaviour is the reason the constant exists at all. PhpRedis is a PECL extension, so it has to be compiled or installed into your PHP, and if it is not there the plugin falls back to Predis, which is a pure PHP library with no extension requirement. Relay is the third option and is a separate commercial product. So the constant is there for the case where you have more than one available and want to be explicit, or where the default is not what you want.

The connection constants are the ordinary set. `WP_REDIS_HOST` defaults to `127.0.0.1` and `WP_REDIS_PORT` to `6379`. `WP_REDIS_PATH` is the path to the Unix socket, and `WP_REDIS_SCHEME` is `tcp` by default and can be `tcp` or `unix`. `WP_REDIS_DATABASE` selects the database from 0 to 15, which is the Redis logical database feature.

`WP_REDIS_PREFIX` is the one worth understanding properly. The description says it is the prefix used for all cache keys to avoid data collisions, that it replaces `WP_CACHE_KEY_SALT`, and that it should be human readable and not a salt. That is a better instruction than it looks. A salt is a random string that nobody can read, which is fine for a security salt and useless for an operational one, because a human-readable prefix is what lets you look at the Redis keyspace and see which site or which environment a key belongs to. If you share a Redis instance across several WordPress installs, this is the setting that keeps them apart.

`WP_REDIS_PASSWORD` covers the password and also supports Redis ACLs, as an array of a username and a password. `WP_REDIS_TIMEOUT` is the connection timeout in seconds and `WP_REDIS_READ_TIMEOUT` the timeout for reading and writing, both with a default of one second. `WP_REDIS_MAXTTL` sets the maximum time-to-live of cache keys, defaulting to zero, which means no cap.

And `WP_REDIS_IGNORED_GROUPS` is a list of groups that should not be cached between requests, with the FAQ linked for the details. That is the escape hatch for the case where a value must not be persisted, and it exists because the plugin caches a lot of WordPress internals that some sites legitimately change at runtime.

## The unsupported options, and why they are documented at all

The configuration table has three sections, and the third one is the most interesting.

The advanced options include the deprecated `WP_CACHE_KEY_SALT`, which is superseded by `WP_REDIS_PREFIX`, so a site that has been running the plugin for years can move the setting across. There is `WP_REDIS_SSL_CONTEXT` for TLS connection options with the `tls` or `rediss` scheme, `WP_REDIS_FLUSH_TIMEOUT` at five seconds, marked experimental, and `WP_REDIS_RETRY_INTERVAL` in milliseconds between retries, which is PhpRedis only. `WP_REDIS_PERSISTENT` decides whether connections are persistent and can take a non-empty connection identifier string. `WP_REDIS_GLOBAL_GROUPS` lists additional groups treated as global on multisite networks, which matters because a multisite install has several caches and some groups should be shared.

Then the operational switches, and these are worth reading as a group. `WP_REDIS_IGBINARY` turns on the igbinary PHP extension for serialization, which is a real performance choice because the standard serialiser is slow. `WP_REDIS_DISABLED` is described as an emergency switch to bypass the object cache without deleting the drop-in, which is the setting you reach for when the cache is suspected of causing a problem and you need the site up now. `WP_REDIS_DISABLE_GROUP_FLUSH` disables group flushing with a Lua script and uses a `flushdb` call instead, which is a blunt instrument kept for when the Lua path misbehaves. `WP_REDIS_DISABLE_DROPIN_CHECK` disables the extended drop-in write test, and `WP_REDIS_DISABLE_DROPIN_AUTOUPDATE` disables the drop-in auto-update, which matters if you manage the drop-in file yourself.

The metrics side has `WP_REDIS_METRICS_MAX_TIME`, the maximum number of seconds metrics are stored, defaulting to 3600, plus `WP_REDIS_DISABLE_METRICS` to turn collection off, `WP_REDIS_CHART_COLOR` to override the admin metrics chart colour, `WP_REDIS_LOAD_APEXCHARTS` to control whether the charting script is loaded, and `WP_REDIS_DISABLE_ADMINBAR` for the admin bar display.

Then the third table, the unsupported options, and the framing is unusual and good. They are options that exist but should not, that may break without notice in future releases, and that will not receive any support from the team. There are three: `WP_REDIS_GRACEFUL`, which prevents exceptions from being thrown but will cause data corruption, and `WP_REDIS_SELECTIVE_FLUSH` and `WP_REDIS_UNFLUSHABLE_GROUPS`, both of which use a slow Lua script.

Publishing a list of settings that are known to be dangerous, with the danger stated, is better than omitting them. A developer debugging a broken install will find these flags in the documentation rather than in a forum post, and the framing tells them exactly what the trade is: `WP_REDIS_GRACEFUL` will make your site stop throwing and start returning wrong data.

## Three ways to reach the server

The connection examples in the README cover the three arrangements that matter in production, and each one is a small amount of code in the WordPress configuration file.

The first is a Unix socket, which avoids a TCP round trip and the associated network stack entirely, and is the right choice when Redis runs on the same machine as WordPress.

```php
define( 'WP_REDIS_SCHEME', 'unix' );
define( 'WP_REDIS_PATH', '/var/run/redis.sock' );
```

The second is TCP with TLS, which is the arrangement when the Redis server is somewhere else, including a managed service.

```php
define( 'WP_REDIS_SCHEME', 'tls' );
define( 'WP_REDIS_HOST', 'master.ncit.ameaqx.use1.cache.amazonaws.com' );
define( 'WP_REDIS_PORT', 6379 );
```

The host in that example is an Amazon ElastiCache endpoint, which is the managed Redis service. Pointing WordPress at a managed cache over TLS is the normal shape of a hosted deployment.

The TLS options are set separately, and the example disables peer verification, which is a configuration you should copy carefully.

```php
define( 'WP_REDIS_SSL_CONTEXT', [
    'verify_peer' => false,
    'verify_peer_name' => false,
]);
```

Turning off peer and peer name verification means the connection is encrypted but not authenticated, which defeats most of the point of TLS and leaves the connection open to interception by anything that can get between you and the cache. The example is in the documentation because that is a setting people need when their certificate does not match the hostname they connect to, and it is exactly the setting to fix rather than copy.

The third is ACL authentication, where the password constant takes an array of a username and a password rather than a string.

```php
define( 'WP_REDIS_PASSWORD', [ 'username', 'password' ] );
```

Redis ACLs, which arrived in Redis 6, let you create a user with its own password and its own set of permitted commands, so the WordPress connection can be a user that can read and write a set of keys and nothing else. On a shared instance, where the same Redis serves several applications, that is the difference between one compromised site and one compromised site.

Together with the replication, sentinel and clustering support named in the plugin description, the picture is a cache backend that is meant to be pointed at a real, professionally run Redis rather than a container on the same box.

## What the repository contains, and the state of the project

The repository layout is a conventional WordPress plugin with a modern toolchain attached, and it is worth noting what is in it.

At the top level there is `redis-cache.php`, the plugin bootstrap, an `includes/` directory for the plugin's own code, a `dependencies/` directory, `assets/` for the admin interface, `languages/` for translations, and `tests/`. There is a `composer.json`, so the plugin's own dependencies are managed with Composer even though the plugin itself is installed from the WordPress plugin directory.

The static analysis setup is the part that says something about the project. There is a `phpcs.xml` for coding standards, a `phpstan.dist.neon` for PHPStan, and a `phpunit.xml.dist` for the test suite. A plugin that handles cache serialisation of arbitrary WordPress objects has to be careful, and the presence of a static analyser and a coding standard configuration is the visible form of that care.

The documentation is split across the README, an `INSTALL.md` and an `FAQ.md`, and the README points at the latter two for installation instructions and for troubleshooting common errors. There is a `CHANGELOG.md` and a `readme.txt`, the latter being the format the WordPress.org plugin directory requires, so the same content is maintained in two places for two audiences.

The version history is the thing to weigh. The recorded releases are 3.0.0 from 2026-09-18, 2.8.0 from 2026-05-04 and 2.7.0 from 2025-09-29, with the last push on 2026-10-07. So a 3.0 release in September 2026 after a 2.x line that ran for over a year, and a branch still being worked on afterwards.

A major version bump for a WordPress plugin is a signal, and in this case it comes with a set of changes to the configuration surface: the deprecation of `WP_CACHE_KEY_SALT` in favour of `WP_REDIS_PREFIX` and the addition of several switches is the kind of thing that happens when the maintainers reorganise how the plugin behaves. If you are upgrading from a 2.x install, the changelog is the document to read, and the `WP_CACHE_KEY_SALT` deprecation notice tells you at least one setting that will need attention.

The alternative to this plugin is the usual one, which is that a good cache plugin is not a substitute for a good site. The WordPress object cache is a symptom of the same inefficiency that a full-page cache addresses, and the order that pays off is usually to fix the queries first, cache the pages second and cache the objects third. The plugin's own advice, in the fact that it exposes metrics and a debug view, is a good model for how to approach it: measure, then change one thing.

## Conclusion

Redis Object Cache suits a WordPress site whose repeated database queries are the bottleneck, particularly one on WooCommerce where the object cache is under constant pressure from autoloaded options and product data. It does not suit a site that has not measured where its time goes, since a page cache or a better query will often beat a persistent object cache. Verify first that your Redis version and PHP extension match the client you select, that the key prefix is set to something readable and unique to the site so a shared Redis instance does not collide, and that you read the unsupported options list before using anything in it, since the documentation says those may break without notice and receive no support.

## FAQ

### What does the Redis Object Cache plugin do?

It provides a persistent object cache backend for WordPress powered by Redis, so values cached during one request are available to the next. It supports Predis, PhpRedis and Relay as clients, and replication, sentinels, clustering and WP-CLI.

### How do I choose between Predis, PhpRedis and Relay?

The WP_REDIS_CLIENT constant selects the client and defaults to phpredis when it is installed, otherwise predis, with relay as the third option. Predis is pure PHP and needs no extension, PhpRedis is the faster PECL extension, and Relay is a separate commercial product.

### What is WP_REDIS_PREFIX for?

It is the prefix used for all cache keys to avoid data collisions, it replaces the deprecated WP_CACHE_KEY_SALT, and it should be human readable rather than a salt. That makes it possible to tell which site or environment a key belongs to in a shared Redis instance.

### How do I connect to Redis over TLS with ACL authentication?

Set WP_REDIS_SCHEME to tls along with the host and port, optionally add WP_REDIS_SSL_CONTEXT for the stream options, and set WP_REDIS_PASSWORD to an array of a username and a password for Redis ACL authentication. The documented SSL context example disables peer verification, which is worth fixing rather than copying.

### What is the difference between the supported and unsupported configuration options?

Three options are listed as unsupported: WP_REDIS_GRACEFUL, which stops exceptions being thrown but will cause data corruption, and WP_REDIS_SELECTIVE_FLUSH and WP_REDIS_UNFLUSHABLE_GROUPS, which use a slow Lua script. The documentation says they may break without notice in future releases and receive no support.

## Sources

- [License: GPL-3.0](https://github.com/rhubarbgroup/redis-cache/blob/develop/LICENSE)
- [Project website](https://wordpress.org/plugins/redis-cache/)
- [README](https://github.com/rhubarbgroup/redis-cache/blob/develop/README.md)
- [Releases](https://github.com/rhubarbgroup/redis-cache/releases)
- [rhubarbgroup/redis-cache on GitHub](https://github.com/rhubarbgroup/redis-cache)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rhubarbgroup-redis-cache