Vergleich Was kann Shopware selbst, und was bringt das Plugin dazu?
Shopware bringt den Befehl system:setup:staging mit. Er macht aus einer fertigen Kopie ein Testsystem mit Banner und Mailsperre. Die Kopie selbst legst du von Hand an, mit Server-Zugang und Shell. Hier steht beides Zeile für Zeile.
Ein Befehl für eine fertige Kopie.
bin/console system:setup:staging mit der Konfiguration config/packages/staging.yaml stellt eine Kopie, die schon läuft, auf Staging um. Davor liegt die eigentliche Arbeit: Dateien kopieren, Datenbank exportieren und importieren, die .env anpassen, den Webserver auf die Kopie zeigen lassen. Danach fehlen Zugriffsschutz und Anonymisierung.
Das Plugin übernimmt den Weg dorthin und nutzt am Ende denselben Staging-Modus von Shopware. Banner und robots.txt sind also dieselben wie beim Standard; den Mailversand regelt die Einstellung „Mails“ der Staging-Umgebung.
Shopware-Standard und Staging-Plugin.
| Aufgabe | Shopware-Standard | Staging-Plugin |
|---|---|---|
| Die Kopie anlegen | ||
| Dateien des Shops kopieren | Nicht enthalten, von Hand per Shell oder FTP. | Im Admin, ohne .git, node_modules und Sicherungen; Cache, Protokolle und Warteschlange beginnen leer. |
| Zweite Datenbank befüllen | Nicht enthalten, Export und Import von Hand. | Tabelle für Tabelle mit dem Stand vom Laufbeginn, in kleinen Scheiben; die Datenbank legt das Plugin auf Wunsch selbst an. |
| Adresse und .env der Kopie | Domains der Verkaufskanäle nach Regeln aus der staging.yaml; die .env schreibst du selbst. | Eigene .env-Werte, Domains auf die Adresse der Kopie umgeschrieben, eigene Cache-Kennung. |
| Fortschritt und Abbruch | Nicht enthalten; ein abgebrochener Export beginnt von vorn. | Lauffenster mit jedem Schritt; ein unterbrochener Lauf setzt dort fort, wo er stand. |
| Die Kopie einrichten | ||
| Staging-Modus mit Banner | Ja, mit bin/console system:setup:staging in der fertigen Kopie. | Ja, das Plugin setzt Shopwares Staging-Modus beim Einrichten. |
| Mails aus der Kopie | Versand gesperrt. | Im Mail-Archiv der Kopie, an eine Fangadresse, nur an freigegebene Adressen oder an die echten Empfänger. |
| Apps, Webhooks und Shop-Id | Apps mit App-Secret gelöscht, Shop-Id verworfen. | Wie im Standard (Apps mit App-Server entfernt, neue Shop-Id), dazu Aufrufe über die App- und Webhook-Clients gesperrt und protokolliert. |
| Scheduled Tasks | Nicht abgeschaltet. | Aus, solange „Scheduled Tasks abschalten“ an ist, und das ist die Vorgabe. |
| Suchmaschinen | robots.txt sperrt im Staging-Modus. | robots.txt sperrt, dazu „noindex, nofollow“ auf jeder Seite der Kopie. |
| Daten und Zugang | ||
| Kundendaten in der Kopie | Bleiben, wie sie im Live-Shop sind. | Anonymisiert nach Regelwerk, je Spalte einstellbar, mit Vorschau und Nachweis. |
| Zugriffsschutz | Nicht enthalten. | Kennwortseite vor Storefront und Administration, IP-Adressen ohne Kennwort, Direktlink aus dem Live-Shop. |
| Zugang für die Agentur | Benutzer legst du in der Kopie selbst an. | Standardbenutzer nur in der Kopie und „Zugangsdaten anzeigen“ zum Weitergeben. |
| Betrieb | ||
| Mehrere Staging-Umgebungen | Nicht enthalten. | Je Staging-Umgebung eigener Ordner, eigene Datenbank und eigene Einstellungen. |
| Kopie aktuell halten | Neue Kopie von Hand. | „Daten auffrischen“, „Neu bauen“ und ein Zeitplan täglich, wöchentlich oder monatlich. |
| Unterschiede zum Live-Shop | Nicht enthalten. | Vergleich von Erweiterungen, Einstellungen, Inhalten, Dateien und Datenbankstruktur, je Fund mit Seite. |
| Ablaufdatum | Nicht enthalten. | Laufzeit mit Ablaufdatum und Erinnerung vorher; danach sperrt sich die Kopie. |
| Kopie auf einem anderen Server | Geht, weil du die Kopie selbst anlegst, wo du willst. | Ja, per SFTP auf einem zweiten Server. |
| Views, Trigger und Routinen | Kommen mit, wenn du die Datenbank als Ganzes kopierst. | Kommen nicht mit; die Vorprüfung nennt sie. |
Was Shopbetreiber dazu fragen.
Was macht system:setup:staging genau?
In einer fertigen Kopie ausgeführt, schaltet bin/console system:setup:staging den Mailversand ab, zeigt ein Banner in Storefront und Administration, schreibt die Domains der Verkaufskanäle nach den Regeln aus config/packages/staging.yaml um, löscht Apps mit App-Secret und die Shop-Id, löscht alle Einwilligungen, schaltet eingestellte Erweiterungen ab, setzt eingestellte Systemwerte, bricht ab, wenn schon Elasticsearch-Indizes existieren, und kennzeichnet den Shop als Staging; robots.txt antwortet dann nur noch Disallow: /.
Muss ich mit dem Plugin noch system:setup:staging ausführen?
Nein. Das Plugin setzt Shopwares Staging-Modus beim Einrichten der Kopie selbst. Darum wirken Banner und robots.txt in der Kopie auch dann, wenn das Plugin dort aus ist, bei „Nichts versenden“ auch die Mailsperre. Seine Einstellungen für die Kopie hält das Plugin in config/packages/zz-dvsn-staging.yaml der Kopie.
Was überlässt mir der Standard?
Die Kopie selbst: Dateien kopieren, eine zweite Datenbank befüllen, die .env schreiben, den Webserver anbinden, die Kopie vor Fremden schützen und Kundendaten entfernen. Dafür brauchst du Server-Zugang und Shell, und das bei jeder frischen Kopie wieder.
Wo geht der Standard weiter als das Plugin?
Views, Trigger und Routinen kommen mit, wenn du die Datenbank selbst als Ganzes kopierst. Das Plugin kopiert Tabelle für Tabelle und lässt sie aus; die Vorprüfung nennt sie vor dem Bau.
Weiter im Plugin
-
Einrichten
Der Assistent in sieben Schritten, die Vorprüfung und der erste Bau.
-
Was kopiert wird
Welche Dateien und Tabellen mitkommen, was leer bleibt und wie neu bauen, auffrischen und abbauen wirken.
-
Anonymisierung
Das Regelwerk, die Ersetzungen je Spalte, die Vorschau und der Nachweis zu jedem Bau.
-
Schutz und Zugang
Kennwortseite, IP-Adressen ohne Kennwort, Standardbenutzer, Zugangsdaten und Wartungsmodus.
-
Mails und Aufrufe
Vier Wege für Mails, drei für Aufrufe von Apps und Webhooks, dazu Scheduled Tasks und Analytics.
-
Dienste und Plugins
Suche, Redis, Warteschlange, Reverse-Proxy und Plugins: was die Kopie mit dem Live-Shop teilt.
-
Unterschiede zum Live-Shop
Der Vergleich zeigt Erweiterungen, Einstellungen, Inhalte, Dateien und Datenbankstruktur, je mit Seite.
-
Zeitplan und Automatik
Zeitplan, Laufzeit mit Erinnerung, Flow Builder und Konsolenbefehle.
-
Hosting und Server
Was am Server geschrieben wird, Apache, nginx, eigene Adresse, Datenbankrechte und SFTP.
-
Preise
Was eine Staging-Umgebung kostet, monatlich oder jährlich, und was jeder Plan enthält.