>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3598921. --> Reported by: [darvanen](https://www.drupal.org/user/1068770) Related to !9 !8 >>> <p>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.</p> <p>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.</p> <p>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.</p> <h3>Proposed</h3> <p>Also put the computed lifetime on the view's cacheability metadata, by setting the max-age in <code>alterCacheMetadata()</code>, 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: <code>Cache::PERMANENT</code> bubbles no max-age (tags only), and "cannot determine" leaves the view uncacheable.</p> <h3>Worth knowing</h3> <p>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.</p> <p>Getting the value onto the public <code>Cache-Control</code> header for a CDN or browser is a separate step that core handles inconsistently. The <a href="https://www.drupal.org/project/cache_control_override">Cache Control Override</a> module pairs well with this for that last hop, but it is optional and not a dependency.</p> <h3>Remaining tasks</h3> <ul> <li>Set the max-age in <code>alterCacheMetadata()</code> from the same computed value.</li> <li>Tests: the view's max-age metadata matches the computed lifetime, including the permanent and undetermined cases.</li> <li>Document the whole-page effect and the optional pairing with Cache Control Override.</li> </ul>