litespeedtech
ESI stopped working (tag not flusheable)
I have a setup working for the last 4 year which no problems. Basically we are dropping esi-fragments for price-information into a wordpress-pages and posts. basically all prices are tagged with "tag_price" and more generic tags like "tag_price_beamer" or "tag_price_tvset". When never prices are availiable we drop/flush the tag. Later a (self-brewed) crawler will tick the pages for to refresh esi-fragments in the pages. The same procedure was running for about 4 year. From a couple of days ago we recorded to following issues:
-
the flush of the tag seems not to invalidate the esi-fragment cache
-
if the entire ls-cache is flushed the data is refreshed
-
just flushing a single page-url will not work
-
additionally the crawlers runs are 6-10times longer and produce a lot of more load on the server.
The seems to be entirely related with the 7.x release. The same servers runs the stage- but the prod-instances. The ls-cache most updated first on the stage-instance. Whereas the problem started on the prod-instance BEFORE this instance was updated.
This there a way to clearly check within a html-page if esi is working ? Or can I check somehow if and how many fragments are in the litespeed esi-fragment cache. We are using REDIS for the object cache; are the esi-fragments also stored in REDIS ?
thx for your help
@hcarsten are you able to reproduce the issue on a test server? Please describe me how you test the issue, so I can reproduce it.
Also, please share a report ID with "Passwordless Link" completed. Can you make the link multiple usage and do not expire.
Share only the ID, do not write extra info, for security reason.
please try this:
enable debug log , with debug include URI lsesi , then purge all , open any page that contains ESI , you should see some lsesi=xxxx query string URI shows up in the log , that should also show the tag it attached
@qtwrk @timotei-litespeed when you say "enable debug log" which one you mean (litespeed or wordpress LS-cache). We are on a managed server without access to the webadmin (for ls). Can the debug-parameter also given in the .htaccess or when we emit the esi-marker ?
it's in wp-admin -> LiteSpeed Cache -> Toolbox -> Debut setting
set :
debug log to ON
debug level to Advance
debug include URI lsesi
then purge all , open any page that contains your ESI
then go to Toolbox -> Log View , check if you see any ESI request and what is the tag attached to it
I did still not got this working and we made numerous sessions to trigger down the problem. The entire setup was working till a couple of weeks ago. The weird thing that we encountered lately was that we had an extra functionality in the wordpress admin BE which is using the litespeed_purge-action to flush a "tag" (so in fact every connected to the tag). And here everything works as it should ! BUT in the real-scenario we are working from inside wp-cli task and here the class Purge seems to working differently than in the website backend !
I think this was working in the past, so is there a way to trigger and immediatly process a flushing from within the a wp-cli task ?!?
you can send a random request via curl in CLI to trigger the purge , like curl -XGET -I https://your_domain.com/?random_string
does not really changed anything; still the same problem that in the BE it works and on the cli NOT. Or does it really matters that the url is "/?random_string" ?
yes, you need to put something like a random string, to bypass cache and hit the PHP execution
right as you frontend page is cached this would not work at all :( so maybe I would need to create a kind of API call to the backend. Or trigger an extra page that is not cached, or ?
yes, that's the part random string comes in to hit a uncached page , and triggers the PHP
what I now did is creating a shortcode that is dropped into a "non-cached" page. Here I will do the flushes for the tags. The page it self is then called with CURL out of the wp-cli task.