Search API Date Limit

Restricts a Search API index to items whose date falls inside a configured range — at tracking time and at indexing time.

Useful whenever an index only needs part of an archive: a news site with decades of content but a search that should only cover recent years, a knowledge base or RAG pipeline with a rolling window, a feed that should stop at a cut-off date.

Why not just a processor?

Search API's documented extension point for "which items get indexed" is an alter_items processor, and this module provides one. But a processor runs after items are tracked and loaded, so every out-of-range item is still counted in the tracker, loaded from storage, and handed to the server before being rejected — cron_limit items at a time.

On an index of 700,000 nodes where only 110,000 qualify, that is 590,000 wasted tracker rows, entity loads and server round trips, spread over thousands of cron runs.

So this module also provides a tracker, which filters before any of that happens. Items outside the range never enter the tracker at all.

What it provides

Plugin Type Works with Filters at Date limit Tracker Entity datasources Tracking time and indexing time Date limit Processor (alter_items) Any datasource Indexing time

Use the processor on its own for correctness on any index. Add the tracker on a large entity index so out-of-range items never enter the tracker in the first place.

When an index uses the Date limit tracker, the processor inherits its range and displays it read-only, so the two can never contradict each other. On an index with any other tracker, the processor carries its own range.

Date sources

Where the date is read from is configurable:

Source Reads Can filter at tracking time Entity base field created, changed, or any timestamp base field Yes Entity date field A configurable datetime or timestamp field Yes Entity date range field A configurable daterange field — compare its start, its end, or whether it overlaps the range Yes Indexed date field A field already on the index with the Date type No

The last one is the only source that works with non-entity datasources, because it reads the value Search API already extracted rather than going back to storage. The trade-off is that it cannot filter at tracking time — nothing is indexed yet at that point — so it is offered to the processor only.

Other modules can register their own sources by tagging a service implementing DateSourceInterface with search_api_date_limit_date_source.

Configuring it

1. Set the index's tracker to Date limit and configure the source, the two bounds, and what to do with items that have no date.
2. On the index's Processors tab, enable Date limit.

Both bounds are optional and inclusive: they cover whole days in the site default time zone, the first from 00:00:00 and the last through 23:59:59. Leaving both empty filters nothing.

Changing the range re-runs tracking automatically. If the range only widened, the index simply picks up the items that now qualify. Any other change schedules a reindex, so items that fell out of range are re-evaluated, rejected, and deleted from the server rather than left behind on it.

Things worth knowing

• Items that leave the range are deleted from the server. That is what makes the limit meaningful, and it is destructive on a write-only backend. Narrow a range deliberately.
• A narrowed range leaves its old rows in the tracker. Items that fall out stay tracked until their next indexing pass, where the processor rejects them and the server deletes them. Their tracker rows then remain, so the tracker total stays higher than the number of items actually in the index. Rebuild the tracker to make the count match — but only after those items have been processed, or they will never be deleted from the server.
• The tracker evaluates the range per entity, not per translation. All translations of an entity share one verdict. The processor is per item.
• Anything the module cannot assess is let through. A datasource that is not entity-backed, a field that does not exist on an item, an unparseable date in configuration: all of these keep the item rather than dropping it. A date limit must never silently discard content it did not actually check.
• "Items with no date" only covers a field that exists and is empty. It is not a catch-all for items the source could not evaluate.

Requirements

Search API 1.39 or newer, on Drupal 10.3+ or 11.

The 1.39 floor is not arbitrary: attribute discovery for Search API plugin types landed in that release, and this module defines its tracker and processor with PHP attributes. On an older Search API neither plugin is discovered at all, with no error to explain why.

The datetime and datetime_range modules are only needed if you want to limit on the field types they provide.

Similar modules

• Search API Date strips the time component off indexed values; it does not affect what gets indexed.
• Search API Exclude Entity excludes entities through a per-entity checkbox field, not a date rule.
• Search API Daterange Filter filters search results at query time, not what enters the index.