Sönke BergerWEB DEVELOPMENT

Shopware 6.7.11.1: Update erst prüfen, dann einspielen

Sönke Berger••5 Min. Lesezeit

Shopware 6.7.11.1 ist kein grosses Feature-Release. Genau das macht es im Alltag leicht, es zu unterschaetzen.

Die offiziellen Release Notes beschreiben 6.7.11.1 als Patch-Release mit drei Bugfixes. Auf GitHub ist derselbe Release-Stand ebenfalls mit Datum 23. Juni 2026 veroeffentlicht. Der Punkt ist also nicht: "Alles stehen lassen, sofort klicken." Der Punkt ist: Auch ein kleiner Patch kann Stellen beruehren, an denen ein Shop empfindlich ist.

Besonders dann, wenn Themes, Plugins, Checkout-Anpassungen oder eigene Integrationen im Spiel sind.

Problem

Viele Shopware-Updates scheitern nicht an Shopware selbst. Sie scheitern an der Umgebung drumherum.

Ein Patch wird direkt in Produktion eingespielt, weil er klein aussieht. Danach faellt auf, dass ein Plugin anders reagiert, ein Theme-Compile haengt, eine Footer-Navigation komisch rendert oder ein Integrationsdetail nicht mehr zu einer lokalen Anpassung passt. Dann ist der eigentliche Zeitfresser nicht das Update. Der Zeitfresser ist die Fehlersuche unter Druck.

Bei 6.7.11.1 sind die offiziellen Bugfixes ueberschaubar: ein Problem rund um verschachtelte Footer-Navigationen und Versand-SEO-URLs in einer VAT-Meldung, ein Fix fuer langsamere oder unzuverlaessige Theme-Compiles durch interne HTTP-Requests, und ein Typfehler rund um den MCP-Authentifizierungslistener bei ersetzten Services.

Das klingt technisch. Fuer Shopbetreiber uebersetzt heisst das: Storefront, Theme-Build und Erweiterungen bleiben Update-Risikozonen. Auch bei einem kleinen Patch.

Diagnose

Vor dem Update sollte deshalb nicht die Frage lauten: "Ist das nur ein Patch?"

Besser ist:

  • Welche Storefront-Bereiche sind bei uns kritisch?
  • Welche Plugins greifen in Theme, Checkout, Navigation, Mail, Suche oder API ein?
  • Gibt es eigene Decorators, Service-Ersetzungen oder tiefe technische Anpassungen?
  • Laeuft der Theme-Compile im Staging reproduzierbar durch?
  • Ist ein Rueckweg vorbereitet, falls Produktion nach dem Update auffaellig wird?

Shopware 6.7.11.0 war kurz davor deutlich breiter: Die Release Notes nennen 112 geschlossene Issues, Korrekturen unter anderem bei Preisrundung, Checkout-Flow, Filesystem-Konfiguration, Webhook-Caching und Elasticsearch-Resilienz sowie neue technische Funktionen wie den experimentellen MCP-Server und erweiterte Sync-API-Resolver. 6.7.11.1 sitzt auf dieser Linie auf.

Das ist wichtig fuer die Einordnung: Wer noch nicht auf 6.7.11.0 ist, spielt mit 6.7.11.1 nicht nur drei Fixes ein, sondern die ganze Strecke bis zu diesem Stand. Dann reicht ein Blick auf die drei Patch-Fixes nicht aus.

Massnahme

Ich wuerde das Update in vier Schritten behandeln.

1. Release-Distanz klaeren

Zuerst pruefen: Von welcher Version kommst du?

Von 6.7.11.0 auf 6.7.11.1 ist es ein kleiner Patch-Schritt. Von einer aelteren 6.7-Version ist es ein groesserer Sprung. Dann gehoeren auch die Release Notes der Zwischenversionen in den Check, mindestens die letzte groessere Stufe vor dem Ziel.

2. Plugin- und Theme-Risiko markieren

Nicht jedes Plugin ist gleich kritisch. Ein reines Admin-Hilfsplugin hat ein anderes Risiko als ein Plugin fuer Checkout, Preise, Versand, Suche, Zahlungsarten, Produktdaten oder Storefront-Ausgabe.

Ich markiere vor Updates immer die Bereiche, die Umsatz oder Bestellbarkeit direkt beruehren:

  • Checkout und Warenkorb
  • Zahlungs- und Versandlogik
  • Preis- und Steuerdarstellung
  • Theme und Storefront-Komponenten
  • Suche, Filter und Produktdetailseiten
  • Schnittstellen zu ERP, PIM, Payment oder Tracking

Diese Punkte werden nicht "mal kurz angeklickt", sondern gezielt getestet.

3. Staging wie Produktion behandeln

Ein Staging-System bringt nur etwas, wenn es nah genug an Produktion ist. Gleiche PHP-Version, gleiche Shopware-Konfiguration, gleiche Plugin-Versionen, realistische Daten, gleiche Build-Schritte.

Fuer 6.7.11.1 wuerde ich besonders den Theme-Compile und Storefront-Bereiche pruefen. Der Release nennt explizit einen Fix rund um theme:compile. Wenn dort vorher Workarounds, Timeouts oder spezielle Deployment-Schritte im Einsatz waren, gehoeren sie in den Test.

Danach einmal den Standard-Pfad durchlaufen: Produkt ansehen, Variante waehlen, in den Warenkorb legen, Checkout starten, Versand und Zahlung auswaehlen, Bestellung bis kurz vor Abschluss pruefen. Bei Testshops mit Dummy-Payment auch komplett durchbuchen.

4. Rollback vor dem Klick festlegen

Ein Update ohne Rueckweg ist kein Update-Prozess, sondern Hoffnung.

Vor dem Einspielen sollten Datenbank-Backup, Dateistand und Deployment-Stand klar sein. Noch besser: Der Rueckweg wurde mindestens einmal geprobt. Wenn nach dem Update ein kritischer Fehler auftaucht, willst du nicht erst dann herausfinden, wo das letzte brauchbare Backup liegt.

Ergebnis

Das Ziel ist nicht, jedes Patch-Release kuenstlich gross zu machen. Das Ziel ist ein ruhiger Ablauf.

Wenn du vorab weisst, welche Version du verlaesst, welche Plugins kritisch sind, ob Staging sauber laeuft und wie der Rollback funktioniert, wird aus "mal eben updaten" ein kontrollierter Vorgang.

Bei 6.7.11.1 ist die Empfehlung deshalb klar: einspielen, aber nicht blind. Besonders Shops mit angepasster Storefront, eigenen Plugins oder komplexeren Integrationen sollten den Patch einmal sauber durch Staging schicken.

Der Aufwand ist klein im Vergleich zu einem kaputten Checkout am Montagmorgen.

Quellen

Mehr lokale Sichtbarkeit?

Kostenlosen SEO-Check anfordern – unverbindlich und persönlich.

Shopware 6.7.11.1: Update erst prüfen, dann einspielen | Sönke Berger