Shopware-Cache — und der Schritt, der kein Cache ist.

Die Ebenen.

Die Spalte in der Mitte ist der Punkt: Zeile drei bis sechs sind keine Caches. Sie zu leeren hilft nicht — sie müssen erzeugt werden. Das ist der häufigste Denkfehler bei Shopware.

Anwendungscache.

Hier liegen aufbereitete Konfiguration, Routen, kompilierte Dienste und Vorlagen. Dieser Zwischenspeicher macht Shopware im Betrieb schnell und ist die Quelle vieler Probleme nach Änderungen.

Zu leeren nach: einem Update, dem Installieren oder Entfernen eines Plugins, Änderungen an Konfigurationsdateien, Änderungen an der Umgebungsdatei und nach dem Einspielen aus einer anderen Umgebung.

Ein widersprüchlicher Zustand äußert sich in Meldungen über nicht gefundene Klassen oder Routen — oder in einer weißen Seite. Das wirkt dramatisch und ist meist in einer Minute behoben (Weiße Seite).

Shopware bietet zusätzlich an, den Cache nach dem Leeren aufzuwärmen — also vorab zu füllen, statt den ersten Besucher warten zu lassen. Bei einem produktiven Shop lohnt das.

HTTP-Cache.

Fertig zusammengebaute Seiten, die ohne erneute Verarbeitung ausgeliefert werden. Der größte Tempofaktor für nicht angemeldete Besucher.

Shopware leert betroffene Einträge bei Änderungen normalerweise selbst. Nicht automatisch passiert es bei Änderungen über Importe, über die Schnittstelle oder direkt in der Datenbank — dann bleibt der alte Stand stehen.

Wichtig für den Betrieb: Warenkorb, Kasse und Kundenkonto dürfen nicht zwischengespeichert werden. Shopware behandelt das korrekt, ein vorgeschalteter Dienst unter Umständen nicht (Caching richtig einrichten).

Theme-Build.

Der Schritt, der am häufigsten fehlt. Shopware erzeugt die Gestaltungsdateien des Shops aus Quelldateien — eigenes Theme, Kernvorlagen und die Beiträge installierter Plugins werden dabei zusammengeführt.

Das heißt: Nach jeder Änderung am Theme, nach jedem Update und nach jeder Plugin-Installation, die Gestaltung mitbringt, müssen diese Dateien neu erzeugt werden. Ohne diesen Schritt läuft der Shop mit dem alten Stand.

Fehlerbilder: Die Seite sieht unformatiert aus. Ein neu installiertes Plugin zeigt sein Element ohne Gestaltung. Eine Theme-Änderung wirkt nicht, egal wie oft man den Cache leert.

Bei einem Shop mit mehreren Verkaufskanälen wird je Kanal gebaut. Wer nur einen aktualisiert, wundert sich über halbe Wirkung.

Verwaltungs-Build.

Dasselbe für die Verwaltungsoberfläche. Auch sie wird aus Quelldateien erzeugt, und Plugins mit eigener Oberfläche liefern dafür Bestandteile.

Fehlerbild: Das Backend lädt ohne Gestaltung oder zeigt ein neu installiertes Plugin nicht an. Das ist kein Fehler, sondern ein fehlender Schritt — und nach jedem Update fällig.

Ein praktischer Hinweis: Dieser Vorgang braucht Arbeitsspeicher und dauert. Auf knapp bemessenen Servern scheitert er daran. Wenn er abbricht, ist das meist kein Shopware-Problem, sondern eine Grenze (Speicherlimit).

Suchindex und Datenindizes.

Shopware bereitet Daten für Suche und Listen vor. Diese Indizes sind kein Cache, sondern aufbereitete Datenbestände — und sie müssen nach größeren Änderungen neu erzeugt werden.

Typischer Fall: Nach einem Produktimport erscheinen neue Artikel nicht in der Suche oder in Kategorielisten. Der Shop funktioniert, die Daten sind da, nur der Index kennt sie nicht.

Der Neuaufbau läuft über die Kommandozeile und kann bei großen Sortimenten dauern. Er lässt sich auch über die Warteschlange abarbeiten — dann läuft er im Hintergrund, und man sollte prüfen, ob er durchgelaufen ist (Wartung).

Wann welcher Schritt.

Diese Tabelle ist der praktische Kern dieser Seite. Wer sie einmal verinnerlicht hat, spart sich die Hälfte der Ratlosigkeit beim Betrieb eines Shopware-Shops.

Wege.

1. Kommandozeile: der Standardweg. Alle Vorgänge laufen dort zuverlässig und ohne Laufzeitgrenze.
2. Verwaltung: Für den Cache gibt es einen Knopf. Für Theme- und Verwaltungs-Build in der Regel nicht.
3. Dateisystem: Notfall, siehe unten.

Punkt zwei ist der Grund, warum Shopware ohne Kommandozeilenzugriff mühsam ist: Die wichtigsten Vorgänge sind dort nicht erreichbar. Für einen produktiven Shop würde ich diesen Zugriff als Voraussetzung behandeln (Hosting-Anforderungen).

Notfall ohne Backend.

Wenn weder Backend noch Kommandozeile erreichbar sind, bleibt der direkte Weg: das Cache-Verzeichnis im Projekt leeren. Shopware baut es beim nächsten Aufruf neu auf — dieser erste Aufruf dauert dann deutlich länger.

Achte auf die Dateirechte: Wird das Verzeichnis unter einem anderen Systembenutzer neu angelegt als dem des Webservers, entsteht das nächste Problem.

Was so nicht geht: Theme und Verwaltung bauen. Dafür braucht es die Kommandozeile — und wenn die fehlt, ist der Shop nach einem Update nicht vollständig wiederherstellbar. Das ist das stärkste praktische Argument für diesen Zugriff.

Vorgeschaltete Dienste.

Bei größeren Shops üblich: ein Zwischenspeicher oder Auslieferungsnetz vor dem Server. Diese Ebene kennt Shopware nicht und bekommt vom Leeren nichts mit.

Typisches Bild: Im Backend stimmt alles, lokal auch, aber Kunden sehen alte Preise. Dann muss dort separat geleert werden — und besser noch: eine Automatik eingerichtet werden, die bei Änderungen auslöst.

Kritisch bei personalisierten Seiten: Ein vorgeschalteter Dienst, der Warenkorb oder Kundenkonto zwischenspeichert, zeigt diese Inhalte unter Umständen anderen Kunden. Das ist ein Datenschutzvorfall, kein Schönheitsfehler — und gehört beim Einrichten ausdrücklich geprüft.

Bei laufendem Verkauf.

Ein Punkt, der bei Shops anders ist: Cache leeren bedeutet, dass die nächsten Aufrufe langsamer sind, weil alles neu gebaut wird. Bei einem Shop mit Betrieb merkt man das.

• Cache aufwärmen nach dem Leeren, statt den ersten Kunden warten zu lassen.
• Zeitpunkt wählen, wenn wenig los ist.
• Theme-Build braucht Rechenzeit — bei schwachen Servern spürbar.
• Index-Neuaufbau über die Warteschlange laufen lassen, nicht blockierend.
• Nach dem Leeren prüfen, ob die Seite korrekt aussieht, bevor Werbung läuft.

Der letzte Punkt klingt banal und ist im Alltag wichtig: Wer kurz vor einer Kampagne den Cache leert und nicht nachsieht, riskiert, dass die ersten tausend Besucher eine halb gebaute Seite sehen.

Typische Fehler.

• Cache geleert, Theme nicht gebaut — der Klassiker.
• Nur einen Verkaufskanal gebaut.
• Verwaltungs-Build vergessen nach einem Update.
• Index nach Import nicht neu erzeugt.
• Vorgeschalteten Dienst vergessen.
• Cache-Verzeichnis mit falschen Rechten neu erzeugt.
• Build bricht ab wegen Arbeitsspeicher — und niemand merkt es.
• Im eigenen Browser geprüft statt im privaten Fenster.

Punkt sieben verdient Aufmerksamkeit: Wenn der Build abbricht, bleibt der alte Stand bestehen. Der Shop läuft also — nur mit der Gestaltung von vorher. Prüf deshalb nach jedem Build, ob er tatsächlich erfolgreich war, statt nur zu sehen, dass die Seite lädt.

Wenn du nicht weiterkommst.

Wenn Änderungen nicht erscheinen oder der Shop nach einem Update kaputt aussieht. Ich finde die Ursache, behebe sie und erkläre dir, was passiert ist. Wenn gerade keine Bestellungen durchgehen, hilft der Notfall-Support, dauerhaft begleitet die Shopware-Wartung.

Orientierungswerte, keine Fixpreise — nach einem kurzen Gespräch bekommst du ein Festpreisangebot.

Wer hilft.

Ich bin Manuel Killert, Webentwickler aus Quakenbrück. Content-Management- und Shopsysteme sind mein Fachgebiet — ich arbeite seit Jahren damit, unterrichte das Thema als Dozent und kenne die Systeme von innen: Datenmodell, Rechtekonzept, Templating, Plugin-Architektur, Caching, Betrieb.

Bei Shopware 6 zahlt sich das besonders aus, weil es auf demselben professionellen Unterbau aufsetzt wie andere ausgewachsene Systeme: Abhängigkeitsverwaltung, Dienste-Container, eine getrennte Verwaltungsoberfläche und eine Schnittstelle für alles. Wer dieses Modell verstanden hat, findet Fehler schnell — und sieht auch, wo ein Shop gegen das Modell gebaut wurde.

Was du bekommst: eine Diagnose in verständlicher Sprache, eine Behebung, die hält, und eine ehrliche Einschätzung dazu, ob dein Shop weiterbetrieben, aktualisiert oder abgelöst gehört — auch wenn die Antwort lautet, dass alles so bleiben kann.