Wordpress LScache Plugin: Cache causing problems with setting/reading options in a plugin
Last Updated on: Wed, 15 Apr 2026 00:00:02 We have run into an issue with a plugin that was thinking it had to update its database even though it was already done, and it caused corruption. The plugin author fears this may affect other portions of the site. They say: Indeed, it was a caching issue that prevented WP options from being read correctly after an update call. Disabled the Litespeed cache plugin, and ? issue gone. As a developer, you always expect that when you call add_option youll be able to use that value in the course of the same request. They were using get_optoin to get a value, then delete_option and add_option to make changes, and when the LiteSpeed cache was active it seems this was not working properly, their plugin was getting a stale value instead of the just-updated value. Is this something that can be fixed by some exclusions in the cache? It isnt a particular page, it is the plugin code that is seeing this problem. This may or not be related, but I was testing WooCommerce 3.9.1 update on our testsite with LiteSpeed Cache enabled, and after it did the update, a number of other plugins thought that the database had not been updated. Running WP-CLI wp wc update triggered 75 updates going back from what looks like v2.00. This behavior is similar to what the other plugin was seeing where options were not set properly, although the cause is not guaranteed to be the same as I have no way to know exactly what happened here. If it matters, the LiteSpeed Cache plugin was disabled by the other developer during testing. When WooCommerce was updated, it was still disabled. I did not see those messages at that time. Then when I realized it was still disabled, I enabled it, and that is when these other messages appeared. Would it be burdensome or troublesome to add those hooks under the advanced options in LSCACHE? add_option delete_option That would ensure it is flushed when options are changed and they cant get old data, right? I wrote a small plugin that simply writes to the debug log the value retrieved from get_option, then does a delete_option, add_option, and prints a new get_option return value. If LSCache object cache feature is enabled, I get the strange behavior the other plugin author ran into. The second get_option returns the same value as the first even though there have been an intervening delete_option and add_option to reset it. If LSCache is running, but object cache is disabled, things work as expected. Even stranger, I hadnt specifically meant to have object caching enabled on the test site, it came as the configuration when I copied from our live site. I do have a redis instance there, but I hadnt set one up on the test site, so I dont even know what it is object caching to if configured for redis but none exists? But this problem is happening on the live site and test site, so it seems something odd is happening in the base LSCache Object Cache feature. Is there a workaround? Hi @scmsteve thanks for the details report, this issue might be related to our recently found bug. Could you try to comment out rows 453 ? 455 in plugin/litespeed-cache/inc/object.class.php: if ( ! $this->_can_cache() ) return null and run the add option again to see does it back to normal? Unfortunately that did not resolve the issue here. I have been away all day, sorry for the delay in getting back to you. Even more disturbing is that, as seen here, get_option at times fails to find the value at all. I dont know if it was deleted and the add call failed because it thought it was still there or what exactly is going on. In fact, after doing the sequence of tests below I looked in the database and this option key is missing entirely, so it seems the delete worked but the add failed. But the value being stored is time() so it should change on every call, the current value is from the first get_option(), then we do a delete_option() and add_option() with a new time() value. So below when it reports the Updated, new value is, and it is the same as the current value , that means it is a cached value and not the new computed value that should be in there. With the object cache portion of LSCache disabled this works as expected and I have never seen the option missing from the database at the end of the get/delete/add/get sequence. [01-Feb-2020 03:09:38 UTC] SCM_DEBUG: Firing test, current value is [01-Feb-2020 03:09:39 UTC] SCM_DEBUG: Updated, new value is 1580526578 [01-Feb-2020 03:10:17 UTC] SCM_DEBUG: Firing test, current value is 1580526578 [01-Feb-2020 03:10:17 UTC] SCM_DEBUG: Updated, new value is 1580526578 [01-Feb-2020 03:10:53 UTC] SCM_DEBUG: Firing test, current value is [01-Feb-2020 03:10:53 UTC] SCM_DEBUG: Updated, new value is 1580526653 [01-Feb-2020 03:11:20 UTC] SCM_DEBUG: Firing test, current value is 1580526653 [01-Feb-2020 03:11:20 UTC] SCM_DEBUG: Updated, new value is 1580526653 [01-Feb-2020 03:12:57 UTC] SCM_DEBUG: Firing test, current value is [01-Feb-2020 03:12:57 UTC] SCM_DEBUG: Updated, new value is 1580526777 [01-Feb-2020 03:15:52 UTC] SCM_DEBUG: Firing test, current value is 1580526777 [01-Feb-2020 03:15:52 UTC] SCM_DEBUG: Updated, new value is 1580526777 [01-Feb-2020 03:15:58 UTC] SCM_DEBUG: Firing test, current value is 1580526777 [01-Feb-2020 03:15:58 UTC] SCM_DEBUG: Updated, new value is 1580526777 Thanks for the update @scmsteve, could you please join our Slack channel and find me(Stanley Cheung at Litespeed) or submit a ticket here for helping us to reproduce the bug, thanks.
LiteCache Rush: Speed comes from using less, not from doing it faster
Reference