Zeitplan und Automatik Wie bleibt die Kopie aktuell, ohne dass du daran denkst?
Ein Zeitplan frischt die Staging-Umgebung von selbst auf, etwa jede Nacht, damit morgens frische Daten da sind. Eine Laufzeit beendet sie zum vereinbarten Datum, und der Flow Builder meldet, wenn etwas schiefgeht.
Auffrischen oder neu bauen, zur vollen Stunde.
Den Zeitplan stellst du auf der Seite der Staging-Umgebung im Reiter „Zeitplan“ ein. Ein geplanter Lauf fragt nicht nach, er nimmt die gespeicherten Einstellungen.
- Was der geplante Lauf macht
- „Daten auffrischen“ kopiert nur die Datenbank neu; Code, Themes und Medien bleiben. „Neu bauen“ baut Dateien und Datenbank ganz neu. Was in der Staging-Umgebung geändert wurde, ist danach weg, beim Auffrischen alles in ihrer Datenbank.
- Wiederholung
- „Täglich“, „Wöchentlich (jeden Montag)“ oder „Monatlich (jeden 01.)“.
- Uhrzeit
- Eine volle Stunde, in der Zeitzone des Live-Shops.
Ein Takt prüft alle fünf Minuten, ob ein Termin fällig ist; der Lauf startet also in den ersten Minuten nach der vollen Stunde. Den Takt führt Shopware als Scheduled Task aus, dafür braucht der Live-Shop einen Worker, einen Konsolen-Worker oder eine offene Administration. Alle Zeitpläne mit nächstem und letztem Lauf zeigt der Zeitplaner.
Eine Staging-Umgebung mit Ablaufdatum.
Mit „Laufzeit begrenzen“ ist „Gültig bis“ Pflicht. Ist der Zeitpunkt erreicht, sperrt die Staging-Umgebung Storefront, Administration und API und zeigt „Staging-Umgebung abgelaufen“.
- Die Daten bleiben erhalten, neue Läufe sind gesperrt, der Zeitplan pausiert und läuft danach weiter.
- Ein späteres Datum oder der Schalter aus und Speichern geben sie wieder frei, sofort auch in der Staging-Umgebung.
- Sieben Tage und einen Tag vor dem Ablauf und am Ablauf selbst löst das Plugin „Staging-Umgebung läuft bald ab“ und „Staging-Umgebung abgelaufen“ aus. Mailvorlagen und passende Flows bringt es mit; die Flows sind zunächst aus, Empfänger wählst du im Flow Builder. Die Erinnerung hängt an „Vor Ablauf einer Staging-Umgebung erinnern“ in den Plugin-Einstellungen.
Ereignisse für Mails, Befehle für Skripte.
| Ereignis im Flow Builder | Wann |
|---|---|
| Staging: Lauf abgeschlossen | Ein Lauf ist fertig, etwa ein Bau, ein Auffrischen, eine Prüfung oder ein Vergleich. |
| Staging: Lauf fehlgeschlagen | Ein Lauf ist gescheitert; das Lauffenster sagt, in welchem Schritt. |
| Staging: Lauf abgebrochen | Jemand hat einen offenen Lauf abgebrochen. |
| Staging-Umgebung läuft bald ab | Sieben Tage und einen Tag vor dem Ablauf. |
| Staging-Umgebung abgelaufen | Am Ablauf selbst. |
dvsn-staging:build- Baut eine Staging-Umgebung mit ihren gespeicherten Einstellungen, jeden Schritt in einem Aufruf; als Argument Name oder ID.
dvsn-staging:tick- Startet fällige Läufe und führt Läufe fort, deren Fenster still geworden ist; derselbe Takt, den sonst der Scheduled Task gibt.
dvsn-staging:expire- Meldet abgelaufene Staging-Umgebungen und nahe Abläufe und entfernt alte Protokolle und Anonymisierungsnachweise.
Wie viele Läufe gleichzeitig laufen dürfen, steht unter „Gleichzeitige Läufe“ (Vorgabe 3). Ein Lauf darüber wartet auf einen freien Platz, statt zu scheitern.
Was Shopbetreiber dazu fragen.
Warum ist mein geplanter Lauf nicht gestartet?
Den Takt führt der Live-Shop als Scheduled Task aus. Er braucht einen Worker, einen Konsolen-Worker oder eine offene Administration, und in den Plugin-Einstellungen muss „Läufe im Hintergrund fortführen“ an sein. War zum Termin schon ein Lauf der Staging-Umgebung offen, wird der Termin übersprungen und nicht nachgeholt; der Zeitplaner zeigt dann „Übersprungen“. Ein Termin gilt eine Stunde; kommt in dieser Stunde kein Takt, fällt er aus. Ist die Staging-Umgebung abgelaufen, pausiert ihr Zeitplan.
Kann sich eine Staging-Umgebung nach einem Projekt selbst abschalten?
Ja. „Laufzeit begrenzen“ mit einem Datum unter „Gültig bis“ sperrt Storefront, Administration und API, sobald es erreicht ist. Die Daten bleiben, neue Läufe sind gesperrt, und der Zeitplan pausiert. Ein späteres Datum gibt sie sofort wieder frei.
Kann ich aus der Konsole oder einem Deployment-Skript bauen?
Ja. bin/console dvsn-staging:build <Name oder ID> baut eine Staging-Umgebung mit ihren gespeicherten Einstellungen, jeden Schritt in einem Aufruf. „Konsolenbefehle erlauben“ in den Plugin-Einstellungen schaltet die Befehle an oder aus.
Bekomme ich eine Mail, wenn ein Lauf scheitert?
Ja, über den Flow Builder. Für „Staging: Lauf fehlgeschlagen“ und die anderen Ereignisse bringt das Plugin Mailvorlage und Flow mit; der Flow ist zunächst aus, du prüfst die Empfänger und schaltest ihn ein.
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.
-
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.