# CMS-Seite aus Cache löschen **URL:** \ **Category:** Shopware 6 (German)\ **Created:** [28. September 2023 um 08:40 UTC](https://forum.shopware.com/t/cms-seite-aus-cache-loeschen/101411 "2023-09-28T08:40:08Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![Frank\_2812](https://avatars.discourse-cdn.com/v4/letter/f/b19c9b/32.png) [@Frank\_2812](https://forum.shopware.com/u/Frank_2812)\ **Post date:** [28. September 2023 um 08:40 UTC](https://forum.shopware.com/t/cms-seite-aus-cache-loeschen/101411/1 "2023-09-28T08:40:08Z")
Hallo, ich möchte eine konkrete CMS-Seite aus dem Cache löschen bzw. von vornherein verhindern, dass diese Seite in „prod“ gecached wird. Hintergrund ist, dass auf der Seite ein eigenes CMS-Element ist, welches Daten von einer externen API einliest. Der Abruf der Daten unterscheidet sich inhaltlich, wenn der Nutzer angemeldet ist, oder nicht. Wenn der Nutzer sich zwischenzeitlich an- oder abmeldet, wird die Seite aber immer aus dem Cache geholt, was zu falschen Inhalten führt (zumindest in „prod“). Da ich keine Stelle kenne, wo man einstellen kann, dass eine Seite nicht gecached werden soll, verfolge ich aktuell den folgenden Ansatz: ```auto class CacheSubscriber implements EventSubscriberInterface { public static function getSubscribedEvents() { return [ HttpCacheItemWrittenEvent::class => 'onHttpCacheItemWrittenEvent' ]; } public function onHttpCacheItemWrittenEvent(HttpCacheItemWrittenEvent $event): void { if (in_array('cms-page-6649bcc2caf84a0baf1dff814326daa1', $event->getTags())) { error_log($event->getItem()->getKey()); } } } ``` Der Subscriber triggert den Moment, nachdem die betroffene CMS-Seite in den Cache geschrieben wurde. Dadurch kann ich den entsprechenden Schlüssel ermitteln. Aber wie kann ich nun den Eintrag aus dem Cache entfernen? Noch besser wäre natürlich direkt zu verhindern, dass die Seite in den Cache wandert. Da habe ich aber kein Ereignis gefunden. Viele Grüße, Frank ---
**Author:** ![werbeagentur\_dietz](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.shopware.com/werbeagentur_dietz/32/18118_2.png) [@werbeagentur\_dietz](https://forum.shopware.com/u/werbeagentur_dietz)\ **Post date:** [29. Februar 2024 um 15:06 UTC](https://forum.shopware.com/t/cms-seite-aus-cache-loeschen/101411/2 "2024-02-29T15:06:30Z")
Hey Frank, ich hänge leider vor dem gleichen Problem. Hast du zufällig inzwischen eine Lösung gefunden? Viele Grüße Benny ---
**Author:** ![Nilik](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.shopware.com/nilik/32/24768_2.png) [@Nilik](https://forum.shopware.com/u/Nilik)\ **Post date:** [14. März 2025 um 08:35 UTC](https://forum.shopware.com/t/cms-seite-aus-cache-loeschen/101411/3 "2025-03-14T08:35:47Z")
Habe das gleiche Problem. ---
**Author:** ![Max\_Shop](https://avatars.discourse-cdn.com/v4/letter/m/58f4c7/32.png) [@Max\_Shop](https://forum.shopware.com/u/Max_Shop)\ **Post date:** [14. März 2025 um 08:53 UTC](https://forum.shopware.com/t/cms-seite-aus-cache-loeschen/101411/4 "2025-03-14T08:53:39Z")
Da wirst du eventuell nur über den Controller weiter kommen. > **[HTTP Cache | Shopware Documentation](https://developer.shopware.com/docs/concepts/framework/http_cache.html#when-will-the-page-be-cached)** > > Documentation for Shopware developers ---
**Author:** ![Nilik](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.shopware.com/nilik/32/24768_2.png) [@Nilik](https://forum.shopware.com/u/Nilik)\ **Post date:** [14. April 2025 um 08:35 UTC](https://forum.shopware.com/t/cms-seite-aus-cache-loeschen/101411/5 "2025-04-14T08:35:16Z")
Das hat leider nicht so funktioniert. Ich habe auch kein Controller, sondern nur ein Resolver. Liegt das daran? ---
**Author:** ![Max\_Shop](https://avatars.discourse-cdn.com/v4/letter/m/58f4c7/32.png) [@Max\_Shop](https://forum.shopware.com/u/Max_Shop)\ **Post date:** [14. April 2025 um 09:34 UTC](https://forum.shopware.com/t/cms-seite-aus-cache-loeschen/101411/6 "2025-04-14T09:34:44Z")
Im Resolver wirst du keine Möglichkeit haben, den Cache zu beeinflussen (vermutet, nicht im Quelltext nachgesehen). Daher mein Verweis auf den Controller. Ich bin in dem Thema aber auch nicht wirklich drin, daher nur die geäußerte Vermutung. ---
**Author:** ![shopware14](https://avatars.discourse-cdn.com/v4/letter/s/4bbf92/32.png) [@shopware14](https://forum.shopware.com/u/shopware14)\ **Post date:** [14. April 2025 um 13:30 UTC](https://forum.shopware.com/t/cms-seite-aus-cache-loeschen/101411/7 "2025-04-14T13:30:09Z")
Danke fürs Teilen, @Max_Shop – das klingt erschreckend vertraut. Wir haben ein sehr ähnliches Verhalten bei dynamischen Produktgruppen festgestellt: Im Backend werden Änderungen (z. B. am Filter) sofort korrekt übernommen – im Frontend hingegen **nur nach einem vollständigen `redis-cli FLUSHALL`**. Selbst gezielte Cache-Invalidierung per `xkey`-Header, Varnish-BAN-Requests oder dem Entfernen relevanter Redis-Keys bringt **keine sichtbare Änderung im Frontend**. Wir setzen dabei ebenfalls Redis und Varnish ein. Du hast weiter oben den Controller `\Shopware\Storefront\Controller\ProductListingController::listing` erwähnt – diesen haben wir ebenfalls geprüft, konnten aber bisher **keinen zuverlässigen Einstiegspunkt für eine nachhaltige Cache-Invalidierung** über diesen Weg finden. Es scheint, als ob der Cache an anderer Stelle (ggf. tief in der Stream-Logik oder CMS-Resolver) hängt. Da wir das Verhalten für mindestens „grenzwertig“ halten (eine _dynamische_ Produktgruppe sollte sich im Frontend auch _dynamisch_ verhalten), haben wir dazu ein GitHub-Issue eröffnet: 👉 [Dynamic Product Groups not updating in storefront (cache/tag invalidation ineffective) · Issue #8221 · shopware/shopware · GitHub](https://github.com/shopware/shopware/issues/8221) Vielleicht hilft unser Erfahrungsbericht ja weiter – oder andere Entwickler:innen erkennen ähnliche Symptome und können das Thema dort oder hier ergänzen. ---
**Author:** ![Max\_Shop](https://avatars.discourse-cdn.com/v4/letter/m/58f4c7/32.png) [@Max\_Shop](https://forum.shopware.com/u/Max_Shop)\ **Post date:** [14. April 2025 um 14:13 UTC](https://forum.shopware.com/t/cms-seite-aus-cache-loeschen/101411/8 "2025-04-14T14:13:49Z")
Ist halt immer die Frage, wie dynamisch Dynamische Produktgruppen sein sollten. Wenn diese bei jedem Request neu berechnet werden würden, das würde sich vermutlich bei der Resourcenlast spürbar auswirken. Ist aber auch wieder nur eine Vermutung. Hatte bisher noch nie das Vergnügen mich mit dem Cache ernsthaft auseinanderzusetzen. ---
**Author:** ![shopware14](https://avatars.discourse-cdn.com/v4/letter/s/4bbf92/32.png) [@shopware14](https://forum.shopware.com/u/shopware14)\ **Post date:** [14. April 2025 um 14:49 UTC](https://forum.shopware.com/t/cms-seite-aus-cache-loeschen/101411/9 "2025-04-14T14:49:20Z")
Ja, genau dieser Punkt beschäftigt uns auch schon eine ganze Weile. Natürlich ist uns bewusst, dass eine vollständige Neuberechnung bei jedem Request aus Performance-Sicht keine Option wäre – aber der Begriff „dynamische Produktgruppe“ suggeriert eine gewisse **Reaktivität** , die derzeit einfach nicht gegeben ist. Besonders kritisch: Sobald **Redis und Varnish** im Einsatz sind, greifen weder die Funktion „Cache leeren“ im Admin noch die Indexierung via Konsole oder Backend. **Das Frontend zeigt weiterhin veraltete Produkt-Listings an.** Es ist aktuell nicht ganz klar, ob Redis oder Varnish oder die Kombination beider Systeme diese Aktualisierung verhindert – aber das Verhalten ist eindeutig reproduzierbar. Die dynamische Produktgruppe wird erst dann korrekt angezeigt, wenn man `redis-cli FLUSHALL` ausführt, also **den gesamten Redis leert** – was in der Praxis keine nachhaltige Lösung ist. Die eigentlichen Cache-Tags (z. B. `product_stream_result_`) werden zwar gesetzt und auch über Varnish übermittelt, doch deren gezielte Invalidierung (per PURGE/BAN oder Redis-Key-Delete) zeigt **keine** sichtbare Wirkung im Frontend. Damit ist die Bezeichnung „dynamisch“ aus unserer Sicht irreführend. Für uns ist das ein ziemlich schwerwiegendes Problem – denn so sind dynamische Produktgruppen in einem performanten, gecachten Setup faktisch nicht nutzbar. ---
**Author:** ![Moorleiche](https://avatars.discourse-cdn.com/v4/letter/m/6f9a4e/32.png) [@Moorleiche](https://forum.shopware.com/u/Moorleiche)\ **Post date:** [14. April 2025 um 20:35 UTC](https://forum.shopware.com/t/cms-seite-aus-cache-loeschen/101411/10 "2025-04-14T20:35:47Z")
Also das spezielle Problem mit den dynamischen Produktgruppen besteht schon länger. In jedem Produkt wird die ID der dynamischen Produktgruppe gespeichert. Wenn man aber die Produktgruppe **ändert** , dann werden die IDs **nicht aktualisiert**. Da muss man halt die Produkte alle neu Indexieren. ---
**Author:** ![shopware14](https://avatars.discourse-cdn.com/v4/letter/s/4bbf92/32.png) [@shopware14](https://forum.shopware.com/u/shopware14)\ **Post date:** [15. April 2025 um 07:21 UTC](https://forum.shopware.com/t/cms-seite-aus-cache-loeschen/101411/11 "2025-04-15T07:21:36Z")
Danke für die Ergänzung – das ist ein wichtiger Punkt. Wir haben genau dieses Verhalten ausführlich untersucht, insbesondere in Kombination mit Redis und Varnish. Die reine Reindexierung (z. B. über das Backend oder CLI) hilft in einem solchen Setup leider nicht weiter. Zwar werden die Produktdaten aktualisiert, aber: - Der Redis-Cache (`product_stream_result_*`, `cms_page_resolver_*`) wird nicht automatisch invalidiert. - Varnish erhält keinen BAN oder PURGE – die Seiten werden also weiterhin aus dem HTTP-Cache ausgeliefert. Ergebnis: Im Backend sieht man die neuen Produkte, aber im Frontend erscheinen sie erst nach einem manuellen `FLUSHALL` in Redis oder einem gezielten BAN in Varnish.