Dienste und Plugins Was passiert mit Redis, Suche, Warteschlange und Plugins?
Die Staging-Umgebung ist eine Kopie der Dateien des Live-Shops und erbt damit jeden Server, den er nutzt. Je Dienst entscheidest du, ob die Kopie ihn teilt oder ihren eigenen Weg geht; vorgewählt ist jeweils der vorsichtige.
Teilen oder trennen, je Dienst.
Die Karte erscheint im Reiter „Einrichtung“, wenn der Live-Shop neben seiner Datenbank weitere Server nutzt. „Wie der Live-Shop“ teilt den Server.
- Suche (Elasticsearch/OpenSearch)
- „Aus“: Die Kopie sucht über die Datenbank. „Eigene Indizes“: gleicher Server, eigener Präfix, der Bau baut sie auf. „Wie der Live-Shop“: Sie schreibt in seine Indizes.
- Hintergrund-Nachrichten (Warteschlange)
- „In der kopierten Datenbank“: Die Kopie arbeitet nur ihre eigenen Nachrichten ab. „Wie der Live-Shop“: Ihre Worker holen auch Nachrichten des Live-Shops ab.
- Reverse-Proxy
- „Aus“: Die Kopie liefert selbst aus. „Wie der Live-Shop“: Jedes Leeren des Caches in der Kopie leert auch den des Live-Shops.
- Redis
- „Aus“, eine eigene Redis-Datenbank auf demselben Server oder „Wie der Live-Shop“, dann teilt die Kopie alles, auch Nummernkreise und Warenkörbe.
- Dateien in der Cloud
- Kein Feld, nur ein Hinweis: Die Kopie nutzt dieselben Dateien wie der Live-Shop. Löscht sie ein Bild oder einen Beleg, ist die Datei des Live-Shops weg.
- Google Analytics
- „Aus“ oder „Wie der Live-Shop“, dann meldet die Kopie an sein Konto.
Jedes Plugin, jede App: an oder aus, nur in der Kopie.
Im Reiter „Einrichtung“ stehen alle installierten Plugins und Apps des Live-Shops, in der Reihenfolge und mit den Titeln aus „Erweiterungen“. Mit der lila Kette gilt der Stand aus dem Live-Shop; löst du sie, bestimmt der Schalter, auch für eine Erweiterung, die im Live-Shop aus ist.
- „Alle deaktivieren“ schaltet alle ab und gilt auch für Erweiterungen, die später dazukommen.
- Immer an bleiben das Staging-Plugin selbst, das Mails und Aufrufe der Kopie abfängt, und Erweiterungen, die das Theme eines Verkaufskanals stellen; ohne sie zeigt die Storefront einen Fehler.
- Apps, die beim Hersteller für den Live-Shop registriert sind, entfernt Shopware aus der Kopie, samt API-Zugang. Brauchst du eine davon, installierst und registrierst du sie dort neu.
- Vor jedem Bau zeigt die Bestätigung die Auswahl noch einmal; dort lässt sie sich nur für diesen Lauf umstellen.
Nacharbeiten, Systemkonfiguration und vier Schalter.
- Nacharbeiten
- Konsolenbefehle aus einer festen Liste, die der Reihe nach als Letztes laufen, wenn die Kopie schon steht. Die Bausteine „Theme bauen“, „Cache wärmen“ und „Sitemap erzeugen“ legen den passenden Befehl an. Ein Fehler steht als Warnung im Protokoll, der Lauf scheitert daran nicht.
- Systemkonfiguration
- Einstellungen, die nur in der Kopie gelten, für alle Verkaufskanäle oder einen: Schlüssel wie
core.basicInformation.shopNameund ein Wert. Der Live-Shop bleibt unverändert. - Erweitert
- „Zugriffsschlüssel der Admin-Benutzer entfernen“, „Nachrichtenwarteschlange leeren“ und „Neues App-Secret erzeugen“ sind an; „Protokolle bei jedem Lauf leeren“ ist aus, die Kopie behält dann ihre Protokolle über jeden Lauf.
Zugangsdaten von Zahlungsanbietern, den Mailserver, eigene Verbindungen von Plugins, Speicher außerhalb von Redis wie Memcached, fest in config/packages eingetragene Redis-Adressen und Dateirechte. Setzt der Server selbst die Datenbank-Adresse (DATABASE_URL), hält die Vorprüfung jeden Bau an, weil die Kopie sonst auf der Datenbank des Live-Shops liefe.
Was Shopbetreiber dazu fragen.
Schreibt die Kopie in meinen Elasticsearch- oder OpenSearch-Index?
Nicht mit „Eigene Indizes für die Staging-Umgebung“: gleicher Server, eigener Präfix, und der Bau baut die Indizes auf, damit die Suche sofort geht. Nur „Wie der Live-Shop (schreibt in seine Indizes)“ teilt sie.
Teilt die Staging-Umgebung Redis mit dem Live-Shop?
Über die Einstellung nur, wenn du „Wie der Live-Shop (teilt alles, auch Nummernkreise)“ wählst. „Eigene Redis-Datenbank auf demselben Server“ gibt der Kopie Datenbanknummern ab „Erste Redis-Datenbank der Staging-Umgebung“; mehrere Staging-Umgebungen nutzen dieselben Nummern, solange du keine andere erste Datenbank einträgst, und die Vorprüfung weist darauf hin. Redis-Adressen, die fest in config/packages stehen, teilt die Kopie immer. Ein Redis-Cluster kennt nur Datenbank 0; dort bleiben „Aus“ oder „Wie der Live-Shop“.
Was ist mit Zahlungsanbietern?
Ihre Zugangsdaten bleiben wie im Live-Shop. Welche Zahlungsplugins in der Kopie aus sind, legst du im Reiter „Einrichtung“ fest und bestätigst es beim Start eines Baus. Für aktive Zahlungsplugins richtest du in der Staging-Umgebung die Sandbox des Anbieters ein.
Kann ich ein Plugin nur in der Kopie abschalten?
Ja. Im Reiter „Einrichtung“ steht jedes installierte Plugin und jede App. Löst du die lila Kette, bestimmt der Schalter, ob es in der Staging-Umgebung an oder aus ist, ohne den Live-Shop anzufassen. „Alle deaktivieren“ schaltet alle ab, auch spätere.
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.
-
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.
-
Vergleich mit dem Standard
Was Shopware mit system:setup:staging selbst kann und was das Plugin dazu bringt.
-
Preise
Was eine Staging-Umgebung kostet, monatlich oder jährlich, und was jeder Plan enthält.