Wordpress LScache Plugin: ESI block not rendering at seemingly random times
Last Updated on: Wed, 15 Apr 2026 00:00:02 Hi there, Im having some issues with LSCache ESI Blocks. Specifically, speaking I have an ESI Block in my plugin that renders a cart-like widget. This block has been working seamlessly for maybe 4-5 months then one day out of the blue it stopped rendering for all users simultaneously. Purging cache resolves the issue immediately but it seems to come back about a week or so later. To verify its not a problem with the template, Ive checked the page source to verify that not even the container div is being rendered. Its almost as if the hook to render it (litespeed_esi_load-nacs-sidebar-cart) is never being called at all. Ive simplified my code to the relevant parts below. I also submitted a report from Toolbox > Report during the time our production site was having issues with this rendering this block. Any advice or potential fix would be greatly appreciated. Report number: YFBQPQQY Report date: 03/15/2022 22:03:35 add_action( plugins_loaded, function() if( function_exists( WC ) ) add_action( litespeed_esi_load-nacs-sidebar-cart, esi_output_cart_sidebar ) add_action( wp_body_open, output_cart_sidebar ) ) function esi_output_cart_sidebar() do_action( litespeed_control_set_nocache ) echo get_cart_sidebar_html() function output_cart_sidebar() if( !apply_filters( litespeed_esi_status, false ) ) echo get_cart_sidebar_html() return echo apply_filters( litespeed_esi_url, nacs-sidebar-cart, NACS Sidebar Cart) / Gets the cart sidebar html / function get_cart_sidebar_html( $is_fragments = false ) $viewbag = [ cart => WC()->cart, is_fragments => $is_fragments, ] $html = nacs_template_part( cart-sidebar, null, $viewbag ) return $html Expand we are also having this problem on our ecommerce store Same website produced some strange CSS errors this afternoon. Exactly the same behaviour as described in these two issues. https://wordpress.org/support/topic/lscache-breaks-css-often/ https://wordpress.org/support/topic/cache-randomly-breaks-styling/ Something strange is definitely happening with the element in particular. It appears that page cache is caching the head component with missing css/js links which its then serving to the public. I honestly have no idea how to reproduce these issues though. verify that not even the container div is being rendered. Its almost as if the hook to render it (litespeed_esi_load-nacs-sidebar-cart) is never being called at all. if you add smoething like error_log(test,3,/path/to/log) in the middle of it , to check if that part of code is executed or not , does it log out ? the missing css/js was different issue , I dont think its related to ESI , in that case was like jscss files were purged but page cache is out of sync and leads to js/css 404 if you add smoething like error_log(test,3,/path/to/log) in the middle of it , to check if that part of code is executed or not , does it log out ? Actually, Ive already tried this. After placing a log message inside the template nothing is executed. Id assume this is because the page is being cached without ESI tags. the missing css/js was different issue, I dont think its related to ESI, in that case was like jscss files were purged but page cache is out of sync and leads to js/css 404 If that was the case I would see the 404 errors in the console but I dont, it appears that css / js isnt being rendered to the at all. It seems to me that sometimes the page is being cached without scripts / styles and sometimes without ESI tags, then that cached version of the page is being served to the public. While brainstorming the issue I thought that maybe it could be something to do with Wordfence where a blocked bot request is being cached but that doesnt really explain why I still see the page content as normal and I would think that only 200 response codes would be cached. Another idea I had is that maybe wordpress has some strange new feature that serves optimized versions of the page to SEO bots but that doesnt make a lot of sense either since the checkout widget should still be visible since its called by the wp_body_open action. Another idea is that maybe the page is cached during a woocommerce update so that function_exists( WC ) returns false and the page is cached without the nessasary ESI tags but that doesnt explain why the whole site CSS / JS was unenqueued. We also havent updated woocommerce on that site recently without doing a full purge and test in incognito afterwards. Weve also had the second issue show up regularly on another one of our clients websites that runs zero custom software at all (Woocommerce, Storefront Theme, WordFence, LSCache) and disabling the page cache has fixed the issue. I really am a little lost on this one to be completely honest. Ive been instructed to disable page caching on this site in the mean time on this site as we want to avoid having a seriously uphappy client but if it pops up again with another site, Ill export copies of the source, css files / js files, error logs and make another report and post it here. yes , it would be wise to set up a stage site for debugging , and lets leave the js/css thing out for the moment , if you just use default setting , with all other optm options OFF, but only enable ESI , how does that go ?
LiteCache Rush: Speed comes from using less, not from doing it faster
Reference