Thanks for the heads up about this.
The way WordPress core works, transients are, when a persistent object cache is active, stored in that cache and retrieved from that cache, not the wp_options table. That’s a core feature, not a persistent object cache plugin feature.
So, if you stored the transient, then activated this persistent object cache (or Till Kruess’s Redis Object Cache), you could not get a transient that was updated before activating it..
Is that what you are doing? Please let me know. I do have a lot of testing that checks that transients function correctly and expire as specified.
I, and Till, have to erase all transients from the wp_options table when deactivating the caches. That’s due to a strange bug in WooCommerce where a stale transient value causes confusion.
(And, it might be possible for your quite short transient name to duplicate something in another plugin. I’ve been bitten by that, and now transients in code I write have absurdly long names containing my plugin name.)
Hi @olliejones, thanks for your response! I’ll check if any of these cases are occurring and get back to you soon.
Hi @olliejones I think I’ve been able to replicate my use case locally.
Here’s what I did: I activated the plugin, set the transient directly in the database via MySQL, and then tried to fetch it in code using get_transient('sso_token'). I couldn’t retrieve the value, which is the same behavior I’m seeing in production (the hosting platform sets the value there and the plugin retrieves it using the code I linked). But, if I repeat the same process with the plugin deactivated, I can retrieve the transient value.
Are you aware of this scenario where setting a transient directly in the database (via MySQL/Adminer/phpMyAdmin, etc.) while the plugin is active could cause retrieval to fail? is that expected? Thanks!
Interesting question. You’re trying to set a transient by writing a row to the options table. You Can’t Do That™. Why not?
When a persistent object cache is present, transients are neither written to nor read from the options table. Instead, they go directly into the persistent object cache. Check out this core code.
https://github.com/WordPress/wordpress-develop/blob/6.8.3/src/wp-includes/option.php#L1540-L1543
If you want your code to be compatible with persistent object caches, you’ll have to use set_transient and get_transient, and make no assumptions about where those transients are actually stored.
And, your transients will all vanish when you activate or deactivate the persistent object cache plugin. (Due to the way the transient API is designed, code using transients must be prepared for them to vanish unpredictably.)
Ahh, got it, that makes perfect sense. We can go ahead and close this ticket now. Thanks a lot for all the help!
I can confirm this issue. set_transient works and I can see the entry being stored into the APCu database, but when using get_transient it doesn’t return anything. It only happens if this plugin is activated. When it’s not, all works fine.
I’ve discovered that the issue doesn’t happens if APCu is disabled, set to “false” in wp-config.php.
