So is it possible to stop your plugin from caching that specific option?
Because the cron
option is loaded as a part of alloptions
, it’s not possible to easily circumvent caching the cron
option.
I have a problem with Redis caching my crons. I have to setup each cron at least a couple of times, cause every event seems to remove it self, especially when site in under heavy load.
This shouldn’t be happening 🙁 Can you share more details on how you’re setting up crons, and steps to reproduce the issue?
I think I solved my problem with ‘pre_option_cron’ filter where I get value from database instead of cache.
Anyhow to set up cron I use ‘wp_schedule_single_event’, then I was calling ‘wp_cache_delete ( ‘alloptions’, ‘options’ )’ hoping for cache to refresh and get updated cron array but it doesn’t seem to have any effect.
Anyhow to set up cron I use ‘wp_schedule_single_event’, then I was calling ‘wp_cache_delete ( ‘alloptions’, ‘options’ )’ hoping for cache to refresh and get updated cron array but it doesn’t seem to have any effect.
Huh. wp_schedule_single_event()
should be deleting the alloptions cache on its own — you shouldn’t need to call wp_cache_delete()
on your own. I think there might be a bigger problem at play.
As I said under heavy load it seemed harder for that event to save, so I think it might be somehow caused by get_option calls in time while it’s cache is being set, but would be rather hard to fix.
I’ve got a similar problem (every once in a while, the slimstat_visit_id
options gets “stuck” and ceases to increment properly) when using the redis cache. I think this is causally related to https://core.trac.wordpress.org/ticket/31245#comment:19.
-
This reply was modified 7 years, 5 months ago by pepe.
Thank you for pointing this out, Pepe. Subscribing to this topic to follow the conversation.