Question
Does Sulu invalidate cached listing pages when a referenced page changes?
Zo Moss
0 reputation · 12 Feb 2021, 14:18 UTC
120.1K views1
Loading…
0 reputation · 12 Feb 2021, 14:18 UTC
We run Sulu 2.x behind Symfony HttpCache and are deciding how to handle cache invalidation for pages that aggregate other content. A typical case: a news overview page built with a smart content block lists the ten most recent articles, and each article is its own page with its own cache tags.
My understanding is that Sulu tags cached responses with identifiers derived from the content structure, so publishing an article purges that article's entry. What is unclear is whether the overview page's cached response also carries tags for every referenced article, or only for the overview structure itself. If it is the latter, a newly published or edited article would leave the overview stale until its configured cache lifetime expires.
The same concern applies to navigation rendering and to moving this setup to Varnish or a CDN later, where Sulu's built-in invalidation may not reach the external layer.
Does Sulu automatically add cache tags for smart content references so the listing page is invalidated when a referenced page changes? Does this behavior differ between Sulu 1.x and 2.x, or between Symfony HttpCache and an external proxy? If tags are not added automatically, is extending the invalidation the intended approach?
35275 reputation · 12 Feb 2021, 15:14 UTC
Yes. In Sulu 2.x the rendering pipeline for a SmartContent block automatically attaches cache tags for every content item it pulls in. When a referenced article is published, edited, or unpublished, the tag for that article is invalidated and the page that contains the SmartContent block is purged by Symfony’s HttpCache (or any proxy that respects X-Cache-Tags).
suluCacheTagResolver service to collect tags from the block’s own structure and from the IDs of all referenced pages.cache_tags option to be set to true in the block configuration; it is enabled by default in 2.x.X-Cache-Tags header. A front‑end cache that understands this header will automatically purge the listing page when any referenced article changes.X-Cache-Tags. If they do not, the listing page will remain stale until the normal cache lifetime expires.curl -I https://your-site.com/news
Look for X-Cache-Tags in the response. It should list the IDs of the 10 most recent articles.
Vary: X-Cache-Tags in your Varnish configuration and confirm that Varnish purges the listing page automatically when the tag is invalidated.app_dev.php/_profiler) inspect the Cache section for the list of tags attached to the request. All referenced article IDs should appear.If you discover that the X-Cache-Tags header does not contain the article IDs, check whether you are using a non‑default SmartContent block implementation. Custom blocks can override the tag resolution logic, which will prevent automatic invalidation. In that case you should either:
ContentEvent) and send explicit purge requests to your external proxy.Does your SmartContent block use the default Sulu block type, or have you implemented a custom block that may alter cache‑tag behaviour?
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.