Store Just WordPress Transients Persistently

WordPress comes with an option of keeping cache in a persistent storage, if provided. It provides a great deal of performance since everything that WordPress was doing repeatedly on each page request now can be saved in the persistent cache storage (APC / Memcached / Redis) and retrieve easily & very fastly without doing much work.

The way to activate that is to drop an object-cache.php file in your wp-content directory which does the heavy lifting for you. Following plugins are available if you want to get started with it:

You don't have a reason to not use object caching unless you are stuck with a plugin which doesn't follow WordPress standards and causes the site to malfunction when a persistent cache storage is used. An example of such a plugin is Wishlist Member plugin.

It simply doesn't work well with persistent object cache because it updates the options table directly by making SQL queries instead of using functions like get_option(), update_option() etc.

I needed to solve the problem, where we could atleast store some of stuff in the persistent cache & hence improving performance. The site for which this was done, is a learning portal where all members are logged in, hence full pages were generated dynamically every single time. To take off some of the load, I developed a plugin in which transients are stored in memcached (persistent storage) so that they can be retrieved very quickly without making SQL queries to the database.

I suggest you use this plugin or use it as a starting point to build what you need. Plugins of this kind, require installation & verification by a developer since its a very barebones-prototype plugin, which does the job of saving transients and retrieving them quickly.

Plugin's repository -

It also overrides wp transient delete-all WP-CLI command so that you can flush transients from both database and memcached (persistent cache storage in use).

Its always a good idea to contribute back your work to the plugin if you build on top of it or extend it, so that other community members can gain from it.

Let me know if you have a question that I can help answer.

Override WP-CLI commands

If you already don't know about WP-CLI, its a pretty great tool to manage a WordPress install via terminal commands. This essentially gives you a lot of power enabling you to interact with the WordPress install just by commands and not having to interact with UI at all. Read more at WP-CLI's homepage.

It can also be extended to add custom commands. The usual way to do can be read in detail here - but the essence is to create a new PHP Class extending from WP_CLI_Command and then just add that class as a handler for a command by calling WP_CLI::add_command().

Now for instance, what if you want to redefine an existing wp-cli command? The way to do that is to create a new PHP Class as if you were creating a new custom command, and then instead of extending it from WP_CLI_Command, extend it from the PHP Class which defines the command you want to override. Simple enough! Here's an example:

wp transient delete-all lets you delete all transients from the database. Yes, database. If you know about persistent caching storage options with WordPress like Memcache or APC, then transients are not actually stored in database anymore. They are simply stored in the persistent cache storage. And since the delete-all subcommand of transient command only runs a SQL query to delete them from database, it simply does nothing if the site uses persistent cache storage (Object cache drop-in object-cache.php, if that reminds you of it).

So you can define a new PHP Class something like this:

if ( defined('WP_CLI') && WP_CLI ) {
class Transient_Mod_Command extends Transient_Command {
public function delete_all() {
// new definition of delete-all subcommand
WP_CLI::add_command( 'transient', 'Transient_Mod_Command' );

Pretty straight-forward, right?

Using the same technique, you can add new sub commands to an existing command as well by simply defining a new method.

On the transient issue note, why that shouldn't be fixed in WP-CLI itself is a question that intrigues me as well. From a quick look at their Github issues, seems like they want to support it in a way it works correctly with persistent cache storage, but haven't got to that place yet. I will see how soon I can create a patch for it and send a pull request.

Have fun with WP-CLI!