Architektur

Eine schnelle Referenz, was im Plugin steckt — nützlich für Theme-Entwickler, Plugin-Autoren und alle, die unerwartetes Verhalten diagnostizieren.

Top-Level-Packages

P2Lab\Cache\
├── Api/              REST-Controller (Admin-Endpoints)
├── Command/          Symfony-Konsolenbefehle
├── Decorator/        Decorators um Core-Services von Shopware
├── DependencyInjection/
├── Entity/           DAL-Definitionen für eigene Tabellen
├── Enum/             Modus- / Strategie-Konstanten
├── Factory/          Cache-Adapter-Factory
├── Framework/        Cache-Store-Implementierung
├── Helper/
├── Message/          Async-Messages, die das Plugin dispatcht
├── MessageHandler/   Handler für diese Messages
├── Migration/        Datenbankmigrationen
├── P2LabCache.php    Plugin-Einstiegspunkt (Lifecycle)
├── Resources/
├── ScheduledTask/    Drei nächtliche Aufräumtasks (+ Handler)
├── Service/          Domain-Services (Großteil der Logik)
├── Storefront/
├── Subscriber/       Event-Subscriber, die in Shopware einklinken
└── ValueObject/

Wichtige Services

Service	Was er tut
`CacheEntryService`	Liest / schreibt die Metadaten-Tabelle `p2lab_cache_entry`
`CacheInvalidationService`	Top-Level-Invalidierungs-API — `clearAll()`, `clearAllProducts()` usw.
`CacheWarmupService`	Findet cachefähige URLs, erzeugt Fortschrittseinträge, batcht sie
`CacheSizeService`	Meldet Cache-Gesamtgröße (Festplatte für Filesystem; Datenbank für Redis / APCu)
`SmartInvalidationAnalyzer`	Feld-zu-Tag-Mapping für den Smart-Invalidierungsmodus
`CacheInvalidationLogService`	Persistiert Zeilen in `p2lab_cache_invalidation_log`
`ReverseProxyLogService`	Persistiert Zeilen in `p2lab_cache_reverse_proxy_log`, plus Analyse-Queries
`CacheTagService`	Baut das Tag-Set für eine gegebene Antwort
`TagParserService`	Parst Tag-Namen zurück in Entitätsreferenzen für die Log-Ansichten
`RequestService`	Inspiziert Anfragen, um Cachefähigkeit und Cache-Key zu bestimmen
`SettingsService`	Liest `system_config`-Werte mit Pro-Sales-Channel-Fallback

Decorators

Decoriert	Zweck
`SalesChannelContextFactory`	Gecachter Sales-Channel-Context für Warmup-Worker
`ReverseProxyGateway`	Fügt xkey-Strategie + Blocklist + Splitting / Verkürzung vor dem Senden von Purges an Varnish hinzu

Subscriber

Subscriber	Hört auf	Was er tut
`CacheEntryFlushSubscriber`	`KernelEvents::TERMINATE`	Persistiert Metadaten neu geschriebener Einträge nach dem Senden der Antwort
`CacheInvalidationSubscriber`	Entity-written-Events	Triggert die Invalidierungspipeline (Manual / Basic / Extended / Precise / Smart)
`CacheResponseSubscriber`	`KernelEvents::RESPONSE`	Speichert die Antwort im Backend, wenn cachefähig; setzt `Cache-Control`-Header
`NotificationMessageSubscriber`	Eigene Plugin-Events	Pusht Admin-Benachrichtigungen (Warmup-Abschluss usw.)
`TagCollectionSubscriber`	Entity-loaded-Events	Sammelt das Tag-Set, das eine Antwort tragen soll
`XkeySubscriber`	Pre-Purge-Event	Wendet Blocklist, Splitting und Verkürzung auf ausgehende xkey-Header an

Async-Messages

Message	Handler	Zweck
`CacheWarmupStartMessage`	`CacheWarmupStartHandler`	Startet einen Warmup-Lauf; spawn’t Batch-Messages
`CacheWarmupBatchMessage`	`CacheWarmupBatchHandler`	Verarbeitet einen Batch URLs

Geplante Tasks

Task	Standard-Intervall	Was er tut
`p2lab_cache.cleanup_cache_entries`	24 h	Entfernt verwaiste `p2lab_cache_entry`-Zeilen
`p2lab_cache.cleanup_invalidation_log`	24 h	Entfernt Invalidierungslog-Zeilen älter als 30 Tage
`p2lab_cache.cleanup_reverse_proxy_log`	24 h	Entfernt Reverse-Proxy-Log-Zeilen älter als 30 Tage

Siehe Geplante Tasks.

Datenbanktabellen

Tabelle	Zweck
`p2lab_cache_entry`	Metadaten für jeden Cache-Eintrag (Größe, Typ, Generierungs- / Hit-Zeit)
`p2lab_cache_invalidation_log`	Jedes Invalidierungsereignis
`p2lab_cache_reverse_proxy_log`	Jeder an Varnish gesendete xkey-Purge
`p2lab_cache_warmup_progress`	Eine Zeile pro Warmup-Lauf; trackt Offset und Zähler
`p2lab_cache_warmup_failed_url`	URLs, die während eines Warmups fehlgeschlagen sind

Tag-Namenskonventionen

Vom Plugin erzeugte Cache-Tags beginnen alle mit p2c-. Die Konventionen:

p2c-product-<id> — volles Produkt-Tag (jede Feldänderung purged)
p2c-product-<id>.<field> — feldbezogenes Tag im Smart-Modus (z. B. .price, .stock)
p2c-product-stock_<id> — reines Bestands-Tag, separat exponiert, damit die product_stock-Blocklist-Kategorie es isolieren kann
p2c-category-<id> — volles Kategorie-Tag
p2c-listing-<categoryId> — Listing-Tag (gepurged, wenn sich ein listing-relevantes Feld eines Mitglieds-Produkts ändert)
p2c-cms-page-<id> — CMS-Seiten-Tag
p2c-buybox-<productId> — Async-Buybox-Tag

Diese Tags werden per xkey an Varnish gesendet und treiben auch das lokale Invalidierungs-Lookup.

Plugin erweitern

Neuen Cache-Typ hinzufügen: Auf KernelEvents::RESPONSE subscriben, Typ über das Response-Objekt setzen und einen Tag-Prefix hinzufügen. getCacheStatsByType() ergänzen, damit es davon weiß.
Feld zum Smart-Mapping hinzufügen: SmartInvalidationAnalyzer decoraten und analyzeProductChange() oder analyzeCategoryChange() überschreiben.
xkey-Blocklist-Kategorie hinzufügen: xkeyTagBlocklist-Config erweitern + passendes Muster in XkeySubscriber ergänzen.