The cache plugin works out exactly when a view's results next change and sets that on the Views result cache. But that only controls the result cache bin. It never reaches the render cache, the page cache, or a reverse proxy or CDN, because those run off the view's cacheability metadata (max-age and tags), which the plugin does not touch.
That gap hits the exact views this module is for. An upcoming or currently-running view changes because time passed, not because content was edited, so no cache tag fires. If the page is cached, which is the normal case for an anonymous archive or events page, it keeps serving the old results past the moment they should have changed. The result cache quietly expiring underneath does nothing for the visitor.
So as it stands the lifetime only really helps where the page is not cached anyway (logged-in or personalised pages), or where the query itself is expensive. For the common public cached page it does not deliver fresh content on time, which is the whole point of the module.
Proposed
Also put the computed lifetime on the view's cacheability metadata, by setting the max-age in alterCacheMetadata(), alongside the existing result-cache handling. Then the render cache and the page caches expire at the right time too. The current outcomes carry over: Cache::PERMANENT bubbles no max-age (tags only), and "cannot determine" leaves the view uncacheable.
Worth knowing
A view that bubbles a max-age caps the whole page that contains it to that lifetime. That is correct, since the page really is stale after that point, but it is a behaviour site builders should expect, so it needs a line in the docs.
Getting the value onto the public Cache-Control header for a CDN or browser is a separate step that core handles inconsistently. The Cache Control Override module pairs well with this for that last hop, but it is optional and not a dependency.
Remaining tasks
- Set the max-age in
alterCacheMetadata()from the same computed value. - Tests: the view's max-age metadata matches the computed lifetime, including the permanent and undetermined cases.
- Document the whole-page effect and the optional pairing with Cache Control Override.
Issue fork vcp4dates-3598921
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
darvanenComment #5
darvanenComment #7
darvanenComment #8
darvanenI was too hasty with the commit, forgot where I was up to, fixing it now.
Comment #11
darvanen