Invalidierungsmodi
Die Invalidierung entscheidet, was aus dem Cache entfernt wird, wenn sich im Admin etwas ändert. P2Lab Cache liefert fünf Invalidierungsmodi, von “niemals etwas anfassen” bis “feldbasierte Analyse jedes Entitäts-Updates”. Wählen Sie den, der zu Ihrem Wunsch nach Kontrolle vs. Aggressivität der Purges passt.
Eingestellt unter Einstellungen → Speed Boost → Core → Einstellungen → Cache-Invalidierungsmodus. Standard ist Smart.
Die fünf Modi im Überblick
Abschnitt betitelt „Die fünf Modi im Überblick“| Modus | Was bei Produktänderung invalidiert wird | Cache-Footprint danach | Am besten für |
|---|---|---|---|
| Manual | Nichts automatisch | Am größten | Sie verwalten Purges selbst per API / CLI |
| Basic | Nur die Produktdetailseite | Groß | Caching einzelner Seiten, manueller Kategorie-Refresh |
| Extended | Produktdetail + kaskadierende Kategorie- und Listingseiten | Mittel | Standard-Abdeckung |
| Precise | Produktdetail + Listings (keine Kategorie-Kaskade) | Mittel-groß | Tiefe Kategoriebäume, wo Kaskade teuer ist |
| Smart (Standard) | Nur Cache-Einträge, die vom tatsächlich geänderten Feld abhängen | Kleinstmöglich | Die meisten Shops |
Nichts wird automatisch invalidiert. Cache-Einträge leben, bis ihre TTL abläuft oder Sie die REST-API / CLI aufrufen.
Wählen Sie diesen, wenn Sie eine eigene Deploy-Pipeline haben, die Purges bereits auslöst, oder wenn Inhalte selten wechseln und Sie staleness bis zum TTL-Rollover tolerieren können.
Invalidiert beim Produktwechsel nur die Produktdetailseite. Kategorie- und Listingseiten behalten ihre Cache-Versionen bis zum TTL-Ablauf.
Nützlich für Shops, in denen Produktdetail-Texte oft wechseln, Listings aber selten relevant sind (z. B. ein Nischenkatalog mit stabiler Kategoriestruktur).
Extended
Abschnitt betitelt „Extended“Baut auf Basic auf und kaskadiert die Invalidierung:
- Produktwechsel → Produktdetail + jede Kategorie, zu der das Produkt gehört + jedes Listing, das es enthält
- Kategoriewechsel → Kategorieseite + Eltern-Kategorien + Listings darunter
Das ist der sicherste Komplettabdeckungsmodus. Er kann überpurgen, wenn ein einzelnes Produkt-Update viele Kategorien berührt.
Precise
Abschnitt betitelt „Precise“Cacht alle Routentypen, überspringt aber die Kategorie-Kaskade:
- Produktwechsel → Produktdetail + Listings
- Kategoriewechsel → nur die Kategorieseite (nicht ihre Kinder)
Wählen Sie Precise bei Shops mit sehr tiefen Kategoriebäumen, wo die Kaskade bei jedem Produkt-Save zu viel purgen würde.
Standard. Smart prüft, welche Felder sich tatsächlich an der Entität geändert haben, bevor entschieden wird, was invalidiert wird. Beispiele:
- Änderung Name des Produkts → invalidiert Listings (Name dort sichtbar) und die Detailseite
- Änderung Beschreibung des Produkts → invalidiert nur die Detailseite (Listings zeigen sie nicht)
- Änderung Lieferzeit des Produkts → invalidiert nur die Buybox (der Teil, der Lieferzeit rendert)
- Änderung Preis des Produkts → invalidiert Listings + Detail + Buybox
- Änderung Name der Kategorie → invalidiert Kategorieseite + Eltern-Listings, nicht aber die enthaltenen Produkte
Das Mapping ist in SmartInvalidationAnalyzer implementiert und deckt alle Standard-Shopware-Felder von Produkten und Kategorien ab. Custom-Felder werden konservativ einsortiert.
Resultat: Ein typisches “Tippfehler in Produktbeschreibung beheben” invalidiert einen Eintrag statt Dutzende.
Kombination mit Reverse Proxy
Abschnitt betitelt „Kombination mit Reverse Proxy“Der in Core eingestellte Invalidierungsmodus steuert den lokalen Cache. Die xkey-Invalidierungsstrategie in Reverse Proxy → Einstellungen macht dasselbe für Varnish-Purge-Tags. Beide sind unabhängig — Sie können lokal Smart und in Varnish Default fahren oder umgekehrt — aber für Konsistenz empfehlen wir das Paar: Smart lokal + Smart xkey oder Precise lokal + Precise xkey.
Siehe Reverse Proxy (Varnish) für die xkey-Seite.
Manuelle Invalidierung von überall
Abschnitt betitelt „Manuelle Invalidierung von überall“Unabhängig vom Modus können Sie Purges jederzeit manuell auslösen:
- Vom Dashboard: Alle leeren / Per-Typ-Buttons
- Per CLI:
bin/console p2lab:cache:clear - Per REST-API:
POST /api/_action/p2lab-cache/clearundPOST /api/_action/p2lab-cache/clear-by-type
Siehe REST-API und CLI für die Parameter.
Unerwartete Invalidierungen diagnostizieren
Abschnitt betitelt „Unerwartete Invalidierungen diagnostizieren“Schalten Sie Invalidierungslog aktivieren in Core → Einstellungen ein. Jedes Invalidierungsereignis wird in der Tabelle p2lab_cache_invalidation_log festgehalten mit:
- Auslösendem Entitätstyp und ID
- Geänderten Feldern (nur Smart)
- Resultierendem Tag-Set
- Anzahl der gelöschten Cache-Einträge
Browsen Sie das Log von der Modul-Unterseite Invalidierungslog. Alte Einträge werden vom Scheduled Task nach 30 Tagen automatisch gelöscht — siehe Geplante Tasks.