Shopware-Testumgebung einrichten: was eine Kopie des Shops nicht mitnehmen darf

Eine Testumgebung ist eine Kopie des Live-Shops: gleicher Code, gleiche Daten, eigene Adresse. Genau darin liegt das Risiko. Die Kopie weiß nicht, dass sie eine Kopie ist. Sie verschickt Mails an echte Kunden, spricht mit echten Zahlungsanbietern und meldet sich bei Apps unter der Kennung des Live-Shops an — bis jemand das abstellt.

Dieser Ratgeber beschreibt, was beim Einrichten abgeschaltet werden muss, was Shopware dafür selbst mitbringt und wo der Befehl des Kerns aufhört.

Der Fall: zwei Shops, eine Kennung

Jede Shopware-Installation hat eine Shop-ID. Sie steht in der Tabelle system_config unter core.app.shopId, in 6.7.2.2 zusätzlich unter core.app.shopIdV2. Unter dieser Kennung registrieren sich Apps mit eigenem Server beim Dienst ihres Anbieters.

Wer die Datenbank des Live-Shops kopiert, kopiert diese Kennung mit. Ab dann gibt es zwei Shops mit derselben ID und unterschiedlicher Adresse.

Das Risiko entsteht an einer bestimmten Stelle. Shopware bemerkt nach dem Kopieren, dass die Adresse in APP_URL nicht mehr zur gespeicherten passt, und fragt in der Administration nach. Wird dieser Dialog auf der Testumgebung mit „Shop dauerhaft umziehen“ beantwortet, registriert Shopware die Apps neu — mit der Adresse und den Zugangsdaten der Testumgebung. Die Dienste dieser Apps sprechen danach nicht mehr mit dem Live-Shop, sondern mit der Kopie. Am Live-Shop selbst ist nichts falsch eingestellt. Die falsche Adresse steht beim Dienst.

Der Fehler fällt spät auf, weil im Live-Shop alles normal aussieht.

Der Quelltext beschreibt die drei Antworten des Dialogs so:

Auf einer Testumgebung ist „dauerhaft umziehen“ fast nie die richtige Antwort.

Was Shopware mitbringt: system:setup:staging

Seit Shopware 6.6.1.0 gibt es einen eigenen Befehl für Testumgebungen:

bin/console system:setup:staging

Er fragt nach einer Bestätigung und lässt sich mit --force ohne Rückfrage ausführen. Im Quelltext von 6.6.10.6 und 6.7.2.2 löst er ein Ereignis aus, auf das im Kern vier Stellen reagieren:

In 6.7.15.1 kommen zwei Möglichkeiten hinzu, die in 6.7.2.2 und 6.6.10.30 fehlen: Der Befehl kann Erweiterungen deaktivieren, die unter shopware.staging.extensions.disable aufgeführt sind, und Systemeinstellungen überschreiben, die unter shopware.staging.system_config stehen. Damit lassen sich zum Beispiel Plugins für Zahlung oder Versand gezielt abschalten. Ausprobiert haben wir beides nicht.

Danach setzt der Befehl den Schalter core.staging. Administration und Storefront zeigen dann standardmäßig einen Hinweis, dass es sich um eine Testumgebung handelt. Shopware 6.7 gibt laut Ratgeber robots.txt in Shopware in diesem Modus nur Disallow: / aus.

Die Umschreibung der Domains wird in config/packages/staging.yaml festgelegt, mit den Typen equal, prefix und regex:

shopware:
  staging:
    mailing:
      disable_delivery: true
    sales_channel:
      domain_rewrite:
        - type: prefix
          match: 'https://www.ihr-shop.de'
          replace: 'https://test.ihr-shop.de'

Die Apps, die der Befehl entfernt, werden in der Testumgebung bei Bedarf neu installiert. Sie bekommen dann eine eigene Kennung.

Was der Befehl nicht anfasst

Der Befehl ändert nur das, was in der Tabelle oben steht. Alles andere bleibt, wie es im Live-Shop war:

Welche Mails Shopware selbst verschickt, listet der Ratgeber Welche Mails Shopware selbst verschickt. Statt den Versand nur abzuschalten, kann ein Mailfänger sinnvoll sein. Dann lassen sich Bestellmails in der Testumgebung prüfen, ohne dass sie jemanden erreichen.

Die Reihenfolge beim Einrichten

Ohne den Staging-Befehl, etwa in einer Version vor 6.6.1.0, nennt Shopware in seiner Dokumentation zwei Schritte als Mindestmaß: Mailversand abschalten und core.app.shopId aus system_config löschen.

Indexierung: Sperre ist nicht Entfernung

Eine Testumgebung gehört nicht in den Google-Index. Disallow: / in der robots.txt verhindert das Crawlen, entfernt aber keine Seite, die schon im Index steht. Dafür gibt es zwei Wege, die Google ausdrücklich nennt: noindex — als Meta-Angabe oder als HTTP-Header X-Robots-Tag: noindex — oder einen Zugriffsschutz. Beide wirken erst, wenn Google die Adresse erneut abruft. Ein noindex funktioniert dabei nur, wenn Google die Seite abrufen darf: Blockiert die robots.txt das Crawling, kann Google die Angabe nicht lesen. Ein Disallow: / zusammen mit noindex hilft deshalb nicht beim Entfernen. Ein Schutz, der mit Status 401 oder 403 antwortet, führt laut Google zum Entfernen bereits indexierter Adressen; eine Anmeldeseite mit Status 200 nicht.

Für eine private Testumgebung bleibt ein echter Zugriffsschutz die bevorzugte Lösung, für eine neue vom ersten Tag an. Dann kommt gar nichts erst in den Index. Mehr dazu im Ratgeber robots.txt in Shopware.

Eine Kopie des Shops ist erst eine Testumgebung, wenn sie keine Mails verschickt, keine echten Zahlungen auslöst, eine eigene Shop-ID hat und für Crawler unerreichbar ist.

Wie wir Shopware-Shops im laufenden Betrieb betreuen, beschreibt die Seite Shopware Support.