Tryby inwalidacji
Inwalidacja decyduje, co zostanie wyczyszczone z cache, gdy coś zmienia się w panelu. P2Lab Cache dostarcza pięć trybów inwalidacji, od “nigdy nic nie ruszaj” do “analiza na poziomie pól każdej aktualizacji encji”. Wybierz ten, który pasuje do tego, ile kontroli chcesz vs jak agresywne mają być purgi.
Ustaw pod Settings → Speed Boost → Core → Settings → Cache Invalidation Mode. Domyślnie Smart.
Pięć trybów na pierwszy rzut oka
Dział zatytułowany „Pięć trybów na pierwszy rzut oka”| Tryb | Co inwaliduje przy zmianie produktu | Rozmiar cache po | Najlepszy dla |
|---|---|---|---|
| Manual | Nic automatycznie | Największy | Sam zarządzasz purgami przez API / CLI |
| Basic | Tylko stronę detalu produktu | Duży | Cache pojedynczych stron, ręczny refresh kategorii |
| Extended | Detail produktu + kaskada strony kategorii i listingu | Średni | Coverage w stylu domyślnym |
| Precise | Detail produktu + listingi (bez kaskady kategorii) | Średnio-duży | Ciężkie drzewa kategorii, gdzie kaskada jest kosztowna |
| Smart (domyślny) | Tylko wpisy cache, które zależą od faktycznie zmienionego pola | Najmniejszy możliwy | Większość sklepów |
Nic nie jest inwalidowane automatycznie. Wpisy cache żyją, aż ich TTL wygaśnie lub wywołasz REST API / CLI, aby purgować.
Wybieraj, gdy masz custom pipeline deploya, który już triggeruje purge, lub gdy treść rzadko się zmienia i możesz tolerować stale strony do rollovera TTL.
Inwaliduje tylko stronę detalu produktu, gdy produkt się zmienia. Strony kategorii i listingu zachowują wersje cache do wygaśnięcia TTL.
Przydatne dla sklepów, gdzie treść detalu produktu często się zmienia, ale listingi rzadko mają znaczenie (np. niszowy katalog ze stabilną strukturą kategorii).
Extended
Dział zatytułowany „Extended”Buduje na Basic i kaskaduje inwalidację:
- Zmiana produktu → detail produktu + każda kategoria, do której produkt należy + każdy listing, który go zawiera
- Zmiana kategorii → strona kategorii + kategorie nadrzędne + listingi pod nią
To najbezpieczniejszy tryb pełnego pokrycia. Może nadmiernie purgować, jeśli pojedyncza aktualizacja produktu dotyka wielu kategorii.
Precise
Dział zatytułowany „Precise”Cache’uje wszystkie typy tras, ale pomija kaskadę kategorii:
- Zmiana produktu → detail produktu + listingi
- Zmiana kategorii → tylko strona kategorii (nie jej dzieci)
Wybierz Precise dla sklepów z bardzo głębokimi drzewami kategorii, gdzie kaskada by za dużo purgowała przy każdym save’ie produktu.
Domyślny. Smart sprawdza, które pola faktycznie się zmieniły w encji, zanim zdecyduje, co inwalidować. Przykłady:
- Zmiana name produktu → inwaliduje listingi (name pokazany tam) i stronę detalu
- Zmiana description produktu → inwaliduje tylko stronę detalu (listingi go nie pokazują)
- Zmiana delivery time produktu → inwaliduje tylko buybox (część rendująca dostawę)
- Zmiana price produktu → inwaliduje listingi + detail + buybox
- Zmiana name kategorii → inwaliduje stronę kategorii + listingi nadrzędne, ale nie produkty wewnątrz
Mapowanie jest zaimplementowane w SmartInvalidationAnalyzer i pokrywa wszystkie standardowe pola produktu i kategorii Shopware. Pola custom są konserwatywnie kubełkowane.
Rezultat: typowy save “popraw literówkę w opisie produktu” inwaliduje jeden wpis zamiast tuzinów.
Kombinacja z reverse proxy
Dział zatytułowany „Kombinacja z reverse proxy”Tryb inwalidacji ustawiony w Core kontroluje lokalny cache. Xkey Invalidation Strategy w Reverse proxy → Settings robi to samo dla tagów purge Varnisha. Oba są niezależne — możesz uruchomić Smart lokalnie i Default w Varnishu, albo na odwrót — ale dla spójności rekomendujemy parować: Smart lokal + Smart xkey, albo Precise lokal + Precise xkey.
Zobacz Reverse proxy (Varnish) po stronie xkey.
Ręczna inwalidacja skądkolwiek
Dział zatytułowany „Ręczna inwalidacja skądkolwiek”Niezależnie od trybu, zawsze możesz wywołać purge ręcznie:
- Z dashboardu: Clear all / per-type clears
- Z CLI:
bin/console p2lab:cache:clear - Z REST API:
POST /api/_action/p2lab-cache/cleariPOST /api/_action/p2lab-cache/clear-by-type
Zobacz REST API i CLI po parametry.
Diagnozowanie nieoczekiwanych inwalidacji
Dział zatytułowany „Diagnozowanie nieoczekiwanych inwalidacji”Włącz Enable Invalidation Log w Core → Settings. Każde zdarzenie inwalidacji jest zapisywane w tabeli p2lab_cache_invalidation_log z:
- typem i ID encji, która to wywołała
- zestawem zmienionych pól (tylko Smart)
- wynikowym zestawem tagów
- liczbą wyczyszczonych wpisów cache
Przeglądaj log z sub-strony Invalidation log modułu. Stare wpisy są automatycznie usuwane przez zadanie zaplanowane po 30 dniach — zobacz Zadania zaplanowane.