Question
Symfony HTTP cache tag invalidation in Sulu 2.x across Symfony 5.4 and 6.x
Rey Lane
0 reputation · 13 Feb 2026, 23:08 UTC
29.8K views
Loading…
0 reputation · 13 Feb 2026, 23:08 UTC
A low-traffic Sulu deployment relies on Symfony HTTP cache with cache tags to keep PHP-FPM usage low. The deployment may run Sulu 2.x on either Symfony 5.4 or 6.x, and it is unclear whether cache-tag invalidation triggered by content edits in the admin UI behaves consistently across those versions.
Symfony cache adapters and tag support changed between Symfony 5 and 6, and Sulu does not automatically map its cache tags to Varnish or Nginx purge logic. The goal is to avoid stale page visibility after editors publish changes while keeping request collapsing and cache hits effective for low traffic.
Does Sulu 2.x expose a stable cache-tag format and purge endpoint across Symfony 5.4 and 6.x, or does the tag handler depend on the pinned Symfony minor version? What configuration boundary determines whether an admin content change invalidates a cached response immediately versus waiting for TTL expiration?
35775 reputation · 14 Feb 2026, 09:20 UTC
Sulu 2.x defines its own cache-tag format, which is stable across Symfony 5.4 and 6.x. The tags (e.g., sulu.content.123, sulu.page.456) are generated by Sulu's CacheTagInvalidator service and do not depend on Symfony's internal cache adapter changes between versions.
Sulu does not expose a generic HTTP purge endpoint. Immediate invalidation of an external cache (Varnish, Nginx, Fastly) only occurs when you explicitly configure a purger—typically via FOSHttpCacheBundle with a Varnish/Nginx purger client. Without that configuration, only Symfony's built-in HttpCache kernel (if enabled) receives invalidation; external caches fall back to TTL expiration.
The boundary is the presence of a configured Purger implementation in the Symfony container that Sulu's CacheTagInvalidator can dispatch to. In practice:
sulufos_http_cache.purger.varnish or .nginx) tagged with fos_http_cache.purger.Symfony 5.4 and 6.x both ship HttpCache with equivalent tag-invalidation support (surrogate-key / Cache-Tags header parsing). Sulu's integration uses the same CacheTagInvalidator interface on both versions. No behavioral difference in tag format or invalidation dispatch exists between Symfony 5.4 and 6.x for Sulu 2.x.
composer.json and config/bundles.php.config/packages/fos_http_cache.yaml (or equivalent). Look for a purger section targeting your reverse proxy.php bin/console debug:container --tag=fos_http_cache.purger.PURGE or BAN request containing the expected sulu.page. tag.Does your composer.lock show friendsofsymfony/http-cache-bundle installed, and is a purger (Varnish/Nginx/Cloudflare) configured in fos_http_cache.yaml? That single fact determines whether invalidation is immediate or TTL-bound.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.