Contao native frontend cache or Symfony HTTP cache for shared-content invalidation

1. Which approach is more reliable for shared content?

When a content element (e.g., a navigation module or a news teaser) is rendered on several pages, the safest guarantee comes from an explicit, URL‑ or tag‑based purge that the element’s save event triggers. Contao’s built‑in page cache is page‑oriented and only knows about the page that was edited; it has no general dependency graph for arbitrary shared modules. Therefore, for multi‑page reuse, an external reverse proxy (Symfony HttpCache or Varnish) with a custom invalidation hook is usually the more reliable choice, provided the bridge is correctly implemented.

2. Does Contao’s native cache clear all dependent pages automatically?

Contao’s native frontend cache clears the edited page and, if it can resolve dependencies, any pages that reference that element. The resolution logic is limited to core cache‑clearing hooks and the extensions installed. In Contao 4.x LTS it only clears the edited page and a handful of obvious dependents; in Contao 5.x the logic has been extended but still depends on the exact extension set. Because the behavior is not guaranteed across all versions, you should verify the list of URLs that are cleared after an edit in your own environment.

3. What purge integration is required when an external reverse proxy is preferred?

1. Expose a purge endpoint. For Symfony HttpCache, the default /purge route is protected by a CSRF token or a shared secret. For Varnish, use the PURGE method or a BAN header.
2. Register a Contao save hook. In config/contao/config.php add:

   \Contao\System::getContainer()->get('contao.framework')->get('contao.framework')->registerHook('savePage', ['Contao\MyModule\CachePurger', 'onSave']);
   

3. Collect affected URLs. Inside onSave, inspect the changed element’s id and query the database for all pages that include it. Store the resulting URLs in an array.
4. Send purge requests. Loop over the URLs and issue HTTP requests:

   $client = new \GuzzleHttp\Client();
   foreach ($urls as $url) {
       $client->request('PURGE', $url, [
           'headers' => ['X-Contao-Secret' => $secret]
       ]);
   }
   

5. Secure the endpoint. Restrict the purge route to the local network or to requests that contain a shared secret header. Avoid exposing a public PURGE endpoint.

With this bridge, every time the shared element is edited, all pages that render it are explicitly invalidated in the proxy, ensuring anonymous visitors always receive fresh HTML.

4. Diagnostic detail needed to fine‑tune the solution

To decide whether the above hook is sufficient, we need to know what type of element is being shared:

• Core content element (e.g., tl_content module)
• Insert tag or global module
• Custom extension that renders its own fragment

Different element types may require different database queries for the dependency list. Please confirm the element type so the hook can be tailored accordingly.