5

I've got a page which returns X-Drupal-Dynamic-Cache: UNCACHEABLE, I've got a suspicion that this is related to a view that is embedded in the page. Though, this made me wonder; is there any way to see what invalidated actually the page cache?

Improve this question

2 Answers 2

Reset to default
4

As suggested in the answer from CG Monroe, enabling the header will show you what contexts you have, a user or session cache context can for example disable caching as well as a max-age 0.

Tracking down exactly where they are coming from can be tricky, I usually debug on the merge methods of the Cache class with a breakpoint set on having the problematic context/age. Certain filters/sorts or so (e.g. a random sort) can cause this, but so can certain block conditions (there is actually a known issue with that, see https://www.drupal.org/project/drupal/issues/2521956).

Improve this answer
4
  • Thanks, I got to the point that I managed to find the user context that has been set. This makes the DynamicPageCacheSubscriber->shouldCacheResponse() say that this page is not cacheable. I'm still not sure where this context is being set. When I use if(in_array("user", $a)) in the merge method of Cache I get tons of hits... Not sure why and how.
    – Ambidex
    Commented Apr 16, 2018 at 9:17
  • Yes, that is always a bit tricky. Usually it is the first hit, because then it often gets merged and merged again with other things many times. From that first call, check the parents and parent structures, which is only really doable with a real debugger and not just some inline debugging code. What we need is something that exposes cache tags and contexts on each render array element similar to twig debug. I think Wim once started with some ideas in drupal.org/project/renderviz. As you can see "More" unfortunatley never came, but maybe that there is already helpful?
    – Berdir
    Commented Apr 16, 2018 at 10:31
  • Renderviz is definitely a useful tool! Thanks for that one.
    – Ambidex
    Commented Apr 16, 2018 at 12:31
  • I also found that placing a breakpoint in the Cache::mergeContexts method helps, but make sure that you first disable render caching in your local settings override file. Otherwise the real source of what added the context to begin with can be obscured.
    – Brian
    Commented Mar 10, 2019 at 14:15
7

The X-Drupal-Cache-Tags header should help with this. Here's how to enable it from this doc:

You can debug cacheable responses (responses that implement this interface, which may be cached by Page Cache or Dynamic Page Cache) by setting the http.response.debug_cacheability_headers container parameter to true, in your services.yml. Followed by a container rebuild, which is necessary when changing a container parameter.

That will cause Drupal to send X-Drupal-Cache-Tags and X-Drupal-Cache-Contexts headers.

Improve this answer
3
  • What the heck does "a container rebuild" mean?
    – phils
    Commented Jul 29, 2021 at 4:43
  • A full cache clear of the Drupal site.
    – CG Monroe
    Commented Jul 30, 2021 at 12:59
  • Thanks. I'm completely baffled as to why they didn't use that extremely-well-understood terminology. I don't think it's just me, either -- a web search for "container rebuild" turned up api.drupal.org/api/drupal/core!lib!Drupal!Core!DrupalKernel.php/… and a bunch of completely irrelevant stuff about docker. AFAICS this terminology isn't being used anywhere outside of very niche discussions of the deep internals of Drupal, so I've no idea why they'd expect readers to know that.
    – phils
    Commented Jul 31, 2021 at 0:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.