ESI settings don't do what we expect?

#1
We re using Drupal 10 and a custom Bootstrap 5 theme and we have tried over and over to use this LiteSpeed Cache module every time a new version comes out but we have never succeeded with it.
We thought it was was time we put pen-to-paper so that someone wise in the community can put us right!

Here goes...
WHEN the LiteSpeed cache kicks in with our shared hosting it is absolutely spectacular and we get pages served in a fraction of a second!

BUT we have never been able to use it because it does not behave as we understand and expect.

SYMPTOMS
For logged in contributor users, TWO things should change:
  1. In the horizontal menu across the top (id=block-bit-by-bit-horizontalmenu), the last menu item should change to 'Me' and led to a submenu as shown below.
  2. The Admin Toolbar (id=toolbar-administration) should show on the lefthand side as shown below.
1741864964316.png

IT WORKS and then it DOESN'T WORK
Sometimes this works fine and then we switch to another tab (within the same session) where both elements should appear the same for the logged-in user but we get neither as below...

1741864980950.png

No amount of browser cache-clearing makes any difference.
CONFIGURATION
As far as we understand it, if we want both those blocks to be considered as ESI blocks then we should configure the LSCache module as below...

1741864997138.png

HELP and ADVICE
Can anyone please offer some help and advice as to whether we have simply misunderstood or whether we have configure the module wrongly.

The facility to be able to use the LS Cache reliable would fundamentally change the end users' experience and so we are very keen to try to get to the bottom of this.

Thank you
 
#3
Thanks @serpent_driver!

Visible somewhere in a header?

How do I view the headers my end - sorry I'm not very up to speed with that side of using the Inspector and I cannot see it anywhere obvious?

I think is only supposed to be present if Drupal internal Page caching is active and I certainly do not have that active at the moment so that's confusing.
 
#5
Ah, but that's correct isn't it - doesn't MISS mean that it IS NOT cached on the Drupal side which is surely what we want if we LSCache to do all the caching?
 
#7
Hi, as I said in #3, I already have Drupal's internal page caching disabled. I get the fact the having two layers of cache is a a no go and is bound to cause trouble.
 

serpent_driver

Well-Known Member
#8
Hi, as I said in #3, I already have Drupal's internal page caching disabled. I get the fact the having two layers of cache is a a no go and is bound to cause trouble.
Drupal cache is still running. Check the response header. If you already have disabled Drupal cache you must purge LiteSpeed cache as well.
 
#9
Thanks for all this @serpent_driver, we are grateful for having access to someone who - unlike me - actually knows this stuff.

Even after:
  1. Clearing all caches via the UI
  2. Truncating DB tables directly
  3. Requesting a LiteSpeed Cache clear via the Drupal UI AND
  4. Requesting a LiteSpeed Cache clear via LS control panel in CPanel
We still see the combination of...

x-litespeed-cache: hit
x-drupal-cache: MISS


But the issue still exists: sometimes the block IDs that are marked as 'ESI' blocks in the sites LSCache configuration page don't appear when they should do - i.e. on every page for UID:1 As I said in the original post, if I forced a cache clear then then come back.

We are certain that, according to the UI at least, Dynamic Page Caching should not be happening...

1742105345873.png

The two internal Drupal cache cannot be explicitly uninstalled

1742105395427.png

But we could set their respective services to...

$settings['cache']['bins']['page'] = 'cache.backend.null';

and

$settings['cache']['bins']['dynamic_page_cache'] = 'cache.backend.null';

in settings.php but will that really make any difference, is that really the cause of all this?

The LiteSpeed Cache documentation talks in places about adjusting ESI settings to exempt certain paths such as ...user/* etc. but even if we had any control over that stuff via the shared hosting UI, surely what we have already set up - that list of block IDs should actually be enough to inform the server-side LS Cache to NOT cache those blocks. After all, isn't that the whole point of that configuration?

1742106078405.png

Can any else with any experience of actually using the Drupal for real please chip in here?

Many thanks
 
Top