Drupal is a registered trademark of Dries Buytaert
cms 2.1.3 — Update released for Drupal core (2.1.3)! drupal 10.5.11 — Update released for Drupal core (10.5.11)! drupal 11.3.11 — Update released for Drupal core (11.3.11)! drupal 11.2.13 — Update released for Drupal core (11.2.13)! drupal 10.6.10 — Update released for Drupal core (10.6.10)! cms 2.1.2 — Update released for Drupal core (2.1.2)! drupal 11.1.10 — Update released for Drupal core (11.1.10)! drupal 10.5.10 — Update released for Drupal core (10.5.10)! drupal 10.4.10 — Update released for Drupal core (10.4.10)! drupal 11.2.12 — Update released for Drupal core (11.2.12)! drupal 11.3.10 — Update released for Drupal core (11.3.10)! drupal 10.6.9 — Update released for Drupal core (10.6.9)! drupal 10.6.8 — Update released for Drupal core (10.6.8)! drupal 11.3.9 — Update released for Drupal core (11.3.9)! drupal 11.3.8 — Update released for Drupal core (11.3.8)! drupal 11.3.7 — Update released for Drupal core (11.3.7)! drupal 11.2.11 — Update released for Drupal core (11.2.11)! drupal 10.6.7 — Update released for Drupal core (10.6.7)! drupal 10.5.9 — Update released for Drupal core (10.5.9)! cms 2.1.1 — Update released for Drupal core (2.1.1)!
← All modules

vcp4dates

5 sites Security covered
View on drupal.org

Inspired by https://www.drupal.org/project/drupal/issues/2968485, this module allows you to set a sensible result cache lifetime on Views that are filtered by a date, so they stay fresh without you having to guess a max-age.

If a view shows content based on the current time (today's news, upcoming events, things happening right now) the results will change at some point in the future. Core's time based caching makes you pick a fixed lifetime: set it too long and the view serves stale results, too short and you throw the cache away for nothing. This module works out the exact moment the result set next changes and expires the cache then.

How it works

Choose Date filter as the caching strategy on a view, then tick the date filter (or filters) that bound the results. The cache is held until the next item is due to enter or leave the view, going by those filters.

It works this out by asking the database for the single nearest item on the other side of each filter, so the lifetime is exact rather than estimated. The results only need rebuilding when that moment arrives, or when the content itself changes, which cache tags already handle.

What it caches well

🗄️ Archive views

A "less than" filter such as event date < now. The result grows over time as content passes the filter, so the cache lasts until the next item is due to appear.

📅 Upcoming views

A "greater than" filter such as event date > now. The result shrinks over time as items pass, so the cache lasts until the soonest item is due to drop out.

⏱️ Currently running views

Two filters together, such as start <= now and end >= now on a date range field. Tick both and the cache lasts until whichever happens first: the next item to begin, or the next to end.

Supported fields and filters

  • Date and datetime fields, including the created and changed node columns.
  • Date range fields, including all day ranges. Filter on the start or the end column, whichever bounds your view.
  • Filters reached through a relationship.
  • The simple operators <, , <code>> and >=.

Things to know

  • Exposed filters are not handled. Their value changes per visitor, so there is no single point to cache against. Use core's Tag based caching for those views.
  • The lifetime is conservative. It never serves stale content, though on a view with other filters it may sometimes rebuild a little earlier than strictly needed.
  • If the lifetime cannot be worked out, caching is turned off for that view rather than risk serving stale results.

Activity

Total releases
1
First release
Jun 2026
Latest release
1 day ago
Release cadence
—
Stability
0% stable

Releases

Version Type Release date
1.0.0-beta1 Pre-release Jun 12, 2026