Transient deletion failing

That’s exactly what I was looking at. I assume that when redis-cache is active and wp_using_ext_object_cache() is true, this applies:

if ( wp_using_ext_object_cache() || wp_installing() ) {
	$result = wp_cache_set( $transient, $value, 'transient', $expiration );
}

calling wp_cache_set() which uses the redis-cache method, not the else part of set_transient() which uses add_option() to store transient and timeout to the database…

But… to my surprise I find that transients still appear in the database, right after set_transient is run. Where / when is this happening? Is redis-cache not doing that? If not, is it WordPress itself or something else on my installation?

I should maybe explain more about the issue I’m facing with this:

I’ve got a small implementation that stores external API queries with set_transient() for an hour to prevent the API being consulted too often and to improve load times. The implementation also has an admin method that will call delete_transient() to allow “flushing” the cached data before expiry, with an admin notice if any stored transient data was successfully deleted.

function delete_my_plugin_data( $transient ) {
	$result = delete_transient( $transient );

	if ( $result ) {
		wp_admin_notice( 'Success!', [ 'type' => 'success' ] );
	} else {
		wp_admin_notice( 'Not found!', [ 'type' => 'error' ] );
	}
}

This works perfectly without Redis Object Cache activated. But with Redis Object Cache is active, delete_transient() does not delete the transient data anymore. At least not from the database. And $result is always false.

To fix this, I had to add an extra routine to delete the transient from the database:

function delete_my_plugin_data( $transient ) {
	$result = delete_transient( $transient );

	// When an object cache is active, make sure the DB entry is deleted as well.
	if ( wp_using_ext_object_cache() ) {
		$result = delete_option( '_transient_' . $transient );
		if ( $result ) {
			delete_option( '_transient_timeout_' . $transient );
		}
	}

	if ( $result ) {
		wp_admin_notice( 'Success!', [ 'type' => 'success' ] );
	} else {
		wp_admin_notice( 'Not found!', [ 'type' => 'error' ] );
	}
}

Is it normal that I should do this “double” routine to delete a transient when redis-cache is used?

Thank you for your insights 🙂

Please note: this is a multisite. It is in fact a multi-network with https://fr.wordpress.org/plugins/wp-multi-network/ … Could this be causing a conflict?

Wanted to limit the test to one network subsite, but I’ll try with –network and let you know 🙂

(WP_REDIS_GRACEFUL is not set in wp-config.php, could it be anywhere else?)

So to confirm:

1. with wp --url=ecranvillage.net transient delete --all the transients get deleted from the database but remain in the redis object cache as expected;
2. running delete_transient from admin will not delete a transient from the redis object cache (and returns false);
3. only clearing the full object cache from admin will get rid of all the transients;
4. after clearing the redis object cache, transients will start appearing in the database again;
5. points 2 and 4 are not supposed to happen, meaning there is some conflict on my network installation.

Could there be any reason outside of the WP install (like missing PHP modules or server settings) that could explain this? If not, I’ll have to do some thorough debugging :/

Just wondering… for a multisite, should I make WP_REDIS_PREFIX dynamic? Something like:

define( 'WP_REDIS_PREFIX', $_SERVER['HTTP_HOST'] );

I found the conflict. It was legacy code from a few years back put in place to work around an issue with transients in the W3 Total Cache Object Cache module at the time. Long since moved away from W3TC, the old work-around remained in place, causing this conflict with Redis Object Cache.

Removing the old work-around, fixed everything.

My sincerest apologies for having bothered you with this. And many many thanks for your time and thoughts, and for the excellent plugin 🙂