Delete Expired Transients Plugin

According to Codex, transients are:

a simple and standardized way of storing cached data in the database temporarily by giving it a custom name and a timeframe after which it will expire and be deleted.

NB: by default they are stored in the database, but if you have an object cache like memcached they won’t be.

Most websites don’t need this plugin. It all depends on what plugins are installed and how they are being used. Some plugins make heavy use of transients to improve website performance, and that can lead to a build up of old transient records in the database. If your wp_options table is growing and causing problems with website performance or backups, this plugin can help you by keeping transients under control.

With the current way that the transients API works, expired transients are only deleted when they are accessed after their expiration date. When transients are user-specific or otherwise fairly unique, they can sit there in the database forever unless some housekeeping task is run to clean them up. WordPress doesn’t currently have such a housekeeping task. That’s what this plugin does.

Only if you have a plugin that is really badly written. Transients can be deleted for a variety of reasons, because by definition they are considered ephemeral. They are considered safe to delete at any time because they are supposedly only ever going to contain information that can be rebuilt.

There are some notable exceptions, e.g. some shopping carts store cart sessions in transients; this is obviously not information that can be easily rebuilt. That data will only be deleted by this plugin if it has expired, which means it would be deleted by WordPress anyway, so it is safe to use this plugin with shopping carts.

On the Tools menu in the WordPress admin, you will find a screen for deleting transients. It tells you how many expired transients there are in your database.

NB: after you install and activate this plugin, the first thing it does is schedule a housekeeping task to delete expired transients. This means that there may not be any transients found when you visit this page in the tools menu straight after installing the plugin, because they may have already been deleted. You probably never need to delete expired transients manually, because they’ll be automatically deleted daily.

No. Object caches like memcached are limited pools of data, and they already purge old data periodically so that they can fit newer data. This means that old transients will be removed from the cache automatically. It also means that new, fresh transients can be removed at any time too, which is why you should never store anything in a transient that can’t be rebuilt easily. See this article on the WPEngine blog for more details: A Technical Transients Treatise.

Not yet. I’ll consider adding a setting for that if it seems to be popular. I reckon daily is often enough even for busy websites. When network activated on multisite, it runs hourly to ensure it can get around all of the sites frequently enough.

If you activate it on individual sites within multisite, each site operates just the same as a stand-alone website.

If you network activate the plugin, it operates differently. You get access to a master admin screen that allows bulk deletion of transients across multiple blogs in a network. This can also help you spot problem sites, by browsing through the list of sites and seeing if any have large numbers of transients. You can find this admin page under Settings on the multisite network admin.

The scheduled task also operates differently, batching up sites to clear expired transients once every hour. The scheduled task can be initiated by activity on any blog. Only 5 blogs are cleaned on each run, so up to 120 blogs will be cleaned each day.

NB: if your website has multiple networks (e.g. if you’re running WP Multi Network) then you’ll need to network activate it on each network. Each activation only cleans the blogs on that network, e.g. activating on example.com will clean blog.example.com, images.example.com, shop.example.com, but not forum.example.net if that’s on a separate network in the multisite.

Here’s a few useful SQL queries to run in MySQL when you are trying to debug what’s happening with transients.

-- transients that are not autoloaded (should be all with expiration times) select option_name, option_value from wp_options where option_name regexp '^(_site)?_transient_.*' and autoload='no' order by option_name; -- transient expirations select option_name, option_value, from_unixtime(option_value) as expiry_time from wp_options where option_name regexp '^(_site)?_transient_timeout_.*' order by option_value desc; -- transient expirations with paired transients (inc. orphans) select t1.option_name, t2.option_name, t1.option_value, from_unixtime(t1.option_value) as expiry_time from wp_options t1 left join wp_options t2 on t2.option_name = replace(t1.option_name, '_timeout', '') where t1.option_name regexp '^(_site)?_transient_timeout_.*' order by t1.option_value desc; -- expired transient expirations with paired transients (inc. orphans) select t1.option_name, t2.option_name, t1.option_value, from_unixtime(t1.option_value) as expiry_time from wp_options t1 left join wp_options t2 on t2.option_name = replace(t1.option_name, '_timeout', '') where t1.option_name regexp '^(_site)?_transient_timeout_.*' and t1.option_value < unix_timestamp() order by t1.option_value desc;