Wordpress LScache Plugin: Custom URL real cron jobs are cached when Guest Mode is on
Last Updated on: Wed, 15 Apr 2026 00:00:02 I use a few plugins that require setting up real cron jobs that have custom cron job URLs. One of the plugins is WP Automatic from CodeCanyon.net. When Guest Mode is on those cron job pages get cached and cause their automatic cron tasks to not run. The crons work when running them manually while logged into WordPress, but not in private browser mode. When Guest Mode and Guest Optimization are on, the cron pages HTTP header shows: x-qc-cache: hit When I turn those options off and clear the cache, the cron pages HTTP header shows: x-litespeed-cache-control: no-cache And the automatic cron tasks run properly again. Ive tried excluding WP Automatics cron URL several different ways, but nothing works. Guest Mode is such a great feature and there has to be another way to make these plugins automatic custom URL cron jobs work properly. Is there some other way to exclude those real cron jobs from being cached while Guest Mode is on? I created Ticket #381902 on litespeedtech.com but I wanted a solution to be available to all LiteSpeed cache users publicly. LiteSpeed Cache v. 4.5.0.1 WordPress v. 5.9.1 WP Automatic v. 3.55.3 I normally keep WordPress and plugins up to date. The page I need help with: https://www.theaegisalliance.com/?wp_automatic=greaterstaff Please try https://github.com/litespeedtech/lscache_wp/commit/3abf315ec93561893918187cf2c724e9d373349a v4.6-a4. It will respect your cache settings. Ive installed v4.6-a4, excluded the cron page URL, cleared the cache, but the cron page is still being cached in private browser mode. It still shows: x-qc-cache: hit please try turn off QC for the time being , and verify it on origin server. Yes, that worked for the time being. It appears that the QUIC.cloud CDN is whats caching the cron page. I had excluded the WP Automatic plugin path and the cron page URL in your plugins CDN settings, but the cron page was still being cached by QUIC CDN. Likely because the CDN exclude is for paths and not full URLs such as the cron page. Ive now turned off QUIC CDN in your plugin and bypassed the CDN on the Quic.Cloud website, and the cron page URL is no longer being cached. Cron page HTTP header in a private browser after changing those settings: x-litespeed-cache-control: no-cache I think this means were getting closer to a solution. I had run into another issue with real cron tasks after using that solution above for now, but found a solution! LiteSpeed caches ObjectCache that uses memcache or redis was causing automated cron tasks to have their next run be decades ago in the past, so they never ran automatically. The WP Crontrol plugin was showing this when running the tasks manually: Hook wp_automatic_hook Arguments none Next Run (UTC-8) 1969-12-31 16:00:01 52 years 2 months ago Action wp_automatic_function() Recurrence Non-repeating` After disabling ObjectCache, that problem went away. But I still think there needs to be a way to exclude the cron pages from being cached by QUIC.cloud CDN. My apologies for any inconvenience this may have caused you, the plugin developers. Im still new to using LiteSpeed cache and QUIC CDN. I will try re-enabling the CDN and see if there are still any issues. I can confirm that theres still an issue with QUIC.cloud CDN caching the cron page, preventing automated cron tasks. Ive turned the CDN off again for the time being until theres a permanent fix. Im sure the caching of the custom URL real cron job was an issue, but as it turns out, that wasnt the only issue. Something else is preventing that cron job from running automatically thats unrelated to your caching plugin. I just cant seem to figure out whats causing this to happen. My apologies for any inconvenience this may have caused. I found that if I choose the use built-in cron settings option for the WP Automatic plugin, the automated cron tasks work again for this plugin! And I have a real alternate cron already set up for the default WordPress cron. While its not the exact solution I was looking for, its still an excellent workaround in my case. Thanks for all of your help plugin support!
LiteCache Rush: Speed comes from using less, not from doing it faster
Reference