Invalidation modes

Invalidation decides what gets purged from the cache when something changes in the admin. P2Lab Cache ships five invalidation modes, from “never touch anything” to “field-level analysis of every entity update”. Pick the one that matches how much control you want versus how aggressive you want purges to be.

Set under Settings → Speed Boost → Core → Settings → Cache Invalidation Mode. Default is Smart.

The five modes at a glance

Mode	What it invalidates on a product change	Cache footprint after	Best for
Manual	Nothing automatically	Largest	You manage purges yourself via API / CLI
Basic	Only the product detail page	Large	Single-page caching, manual category refresh
Extended	Product detail + cascading category & listing pages	Medium	Default-style coverage
Precise	Product detail + listings (no category cascade)	Medium-large	Heavy category trees where cascading is expensive
Smart (default)	Only the cache entries that depend on the actually-changed field	Smallest possible	Most stores

Manual

Nothing is invalidated automatically. Cache entries live until their TTL expires or you call the REST API / CLI to purge.

Pick this when you have a custom deployment pipeline that already triggers purges, or when content rarely changes and you can tolerate stale pages until TTL rollover.

Basic

Invalidates only the product detail page when a product changes. Category and listing pages keep their cached versions until TTL expiry.

Useful for stores where product detail copy changes often but listings rarely matter (e.g. a niche catalogue with stable category structure).

Extended

Builds on Basic and cascades the invalidation:

Product change → product detail + every category the product belongs to + every listing that contains it
Category change → category page + parent categories + listings under it

This is the safest blanket-coverage mode. It can over-purge if a single product update touches many categories.

Precise

Caches all route types but skips the category cascade:

Product change → product detail + listings
Category change → category page only (not its children)

Pick Precise on stores with very deep category trees where the cascade would purge too much on every product save.

Smart

The default. Smart inspects which fields actually changed on the entity before deciding what to invalidate. Examples:

Product name change → invalidates listings (name is shown there) and the detail page
Product description change → invalidates only the detail page (listings don’t show it)
Product delivery time change → invalidates only the buybox (the part that renders delivery)
Product price change → invalidates listings + detail + buybox
Category name change → invalidates the category page + parent listings, but not the products inside it

The mapping is implemented in SmartInvalidationAnalyzer and covers all standard Shopware product and category fields. Custom fields are bucketed conservatively.

Result: a typical “fix a typo in product description” save invalidates one entry instead of dozens.

Combination with reverse proxy

The invalidation mode set in Core controls the local cache. The Xkey Invalidation Strategy in Reverse proxy → Settings does the same job for Varnish purge tags. The two are independent — you can run Smart locally and Default in Varnish, or vice versa — but for consistency we recommend pairing them: Smart local + Smart xkey, or Precise local + Precise xkey.

See Reverse proxy (Varnish) for the xkey side.

Manual invalidation from anywhere

Regardless of mode, you can always trigger purges manually:

From the dashboard: Clear all / per-type clears
From the CLI: bin/console p2lab:cache:clear
From the REST API: POST /api/_action/p2lab-cache/clear and POST /api/_action/p2lab-cache/clear-by-type

See REST API and CLI for the parameters.

Diagnosing unexpected invalidations

Turn on Enable Invalidation Log in Core → Settings. Every invalidation event is recorded in the p2lab_cache_invalidation_log table with:

the entity type and ID that triggered it
the field set that changed (Smart only)
the resulting tag set
the number of cache entries purged

Browse the log from the Invalidation log sub-page of the module. Old entries are pruned automatically by a scheduled task after 30 days — see Scheduled tasks.