# Storefront-Caching

## Übersicht

- **Settings (Theme, robots.txt, …)** werden pro Request über `CacheService::cacheSettings()` geladen (Pool `terraflow.cache.system`, Tag `settings`). Der `StorefrontController` hält **keine** Settings mehr als Singleton-Property.
- **Vollständiges HTML** für die Catch-All-Route `app_storefront_page` (`/{route}`) wird für **anonyme GET-Requests** optional im Pool `terraflow.cache.pages` zwischengespeichert (TTL ca. 2 h, Tags u. a. `pages`, `content`, plus routenbezogen `page_<md5>`).

## Umgebungsvariablen

| Variable | Bedeutung |
|----------|-----------|
| `STOREFRONT_PAGE_HTTP_CACHE` | `1` (Standard): HTML-Page-Cache aktiv, sofern nicht im Dev-Modus. `0`: kein serverseitiges Caching des vollständigen HTML für diese Route (z. B. bei Debugging in Production). |
| `HTTP_CACHE` | `1`: In **Produktion** (`APP_ENV=prod`, `APP_DEBUG=0`) wrappt `public/index.php` den Kernel mit **Symfony HttpCache** (Store unter `var/cache/<env>/http_cache`). Standard `0`. Wird bei „Cache leeren“ / Alt+C mit geleert. |

Konfiguration: `config/packages/terraflow_storefront.yaml` (Default für die Env-Variable).

## Dev vs. Production

- **`kernel.debug: true`**: Es wird **kein** HTML-Page-Cache für `app_storefront_page` genutzt (unabhängig von `STOREFRONT_PAGE_HTTP_CACHE`).
- **Eingeloggte Nutzer / POST**: Kein Page-Cache (personalisierte Antworten).

## HTTP-Header

Ausgelieferte Storefront-HTML-Responses erhalten `Cache-Control: private, must-revalidate, max-age=0`, damit der Browser kein aggressives Caching von dynamischem HTML vornimmt. Statische Hilfsrouten (`robots.txt`, `sitemap.xml`) nutzen `public, max-age=3600`.

## Invalidierung

- Änderungen an **Page**, **Category**, **Settings**, **Media** und seit Erweiterung auch an **CustomFieldValue** (je nach `entityType`) invalidieren die passenden Cache-Tags über `CacheInvalidationListener`.
- Nur **Custom Fields** ohne Änderung der Parent-Entity lösen weiterhin Invalidierung aus (Doctrine-Events auf `CustomFieldValue`).

## Redis / Dateisystem

Pools liegen unter `var/cache/.../pools` bzw. können auf Redis umgestellt sein. Reines Löschen von `var/cache/*` ersetzt nicht zwingend einen getaggten Invalidierungslauf; bei Problemen mit veralteten Seiten gezielt **Cache leeren** im Backend oder Tags invalidieren.