Staging Umgebung / Testsystem / Entwicklungssystem
Um das Cookie zu akzeptieren und das Video zu laden, klicke auf „Video laden“.
Um das Cookie zu akzeptieren und das Video zu laden, klicke auf „Video laden“.
Video
Beschreibung
Highlights
- Beliebig viele Testumgebungen aus der Shopware-Administration erstellen und verwalten
- Isolierte Kopie von Dateien und/oder Datenbank des Live-Shops
- Keine erneute Plugin Lizenzierung notwenig
- Konfigurationen, Plugins, Themes, Updates und individuelle Anpassungen risikofrei testen
- Im Unterverzeichnis oder seperaten Server – flexibel für jedes Hosting-Setup
Features
- Unbegrenzte Staging-Umgebungen parallel betreiben
- Shop-Adressen automatisch auf Staging-URLs umschreiben – Eigene APP-URL sowie individuelle Staging-Domains je Verkaufskanal
- Dateien und Datenbank mit einem Klick synchronisieren - Datenbankverbindung vor der Erstellung testen
- Lokale Kopie auf demselben Server – ohne zweiten Host
- Kopie auf einen separaten Staging-Server übertragen
- Apache und nginx geeignet
- Kundendaten, Bestellungen und Newsletter optional ausschließen
- Mailversand auf Staging automatisch deaktivieren
- Zahlungen automatisch in den Testmodus schalten
- Sensible Zugangsdaten automatisch entfernen oder leeren
- Auswahl welche Backend-Nutzer Zugriff auf Staging erhalten
- Vollständiges Protokoll aller Synchronisationsvorgänge
- Probelauf vor jedem Sync – ohne etwas zu verändern
- Alle Aktionen auch per Kommandozeile oder Cronjob automatisierbar
- Passwörter und Zugangsdaten verschlüsselt gespeichert
Über die Erweiterung
Staging Umgebung – Sicher testen, bevor es live geht
Änderungen am Shop testen, ohne den laufenden Betrieb zu gefährden – das ist der Kern des Staging Umgebung Plugins. Mit wenigen Klicks direkt aus dem Shopware-Backend erstellst du eine vollständige Testkopie deines Shops: Dateien, Medien und Datenbank werden automatisch übertragen. Kein zweiter Server notwendig, kein technisches Vorwissen erforderlich.
Ob Plugin-Updates, Theme-Änderungen, neue Inhalte oder Shopware-Updates – alles wird zuerst in der Testumgebung geprüft. Erst wenn alles funktioniert, geht es live. Dein Shop läuft dabei völlig ungestört weiter.
DSGVO-konform und sicher
Kundendaten, Bestellungen und Newsletter-Empfänger können per Schalter automatisch vom Kopiervorgang ausgeschlossen werden. Der Mailversand wird im Staging automatisch deaktiviert – versehentliche Mails an echte Kunden sind damit ausgeschlossen. Zahlungen werden automatisch in den Testmodus gesetzt. Eine auffällige rote Leiste zeigt jederzeit klar an, ob du gerade im Testsystem oder im Live-Shop arbeitest.
Drei Sync-Modi für jedes Hosting-Setup
Je nach Infrastruktur wählst du den passenden Modus: Die lokale Kopie erstellt das Staging im Unterverzeichnis auf demselben Server – schnell und ohne zweiten Host. Für dedizierte Staging-Server steht der Server-zu-Server-Modus per SSH/rsync zur Verfügung. Teams mit eigenem Deployment-Repository nutzen den Git-basierten Modus, bei dem das Shop-Gerüst per Git-Checkout eingerichtet und Plugins sowie Assets per rsync übertragen werden.
Server-zu-Server-Deployment
Produktion und Staging müssen nicht mehr auf demselben Server liegen. Läuft Deine Testumgebung auf einem komplett anderen Host — ein gängiges Setup bei Managed- oder Shared-Hosting —, deployt das Plugin vollständig per SSH: Dateien und Datenbank werden sicher übertragen und automatisch synchron gehalten, ohne dass jemals eine direkte Verbindung zwischen den beiden Servern geöffnet werden muss.
Jedes Deployment startet mit automatisierten Preflight-Checks, die Fehlkonfigurationen erkennen, bevor überhaupt etwas angefasst wird — inklusive einer harten Sperre gegen versehentliches Überschreiben Deines Live-Shops. Es werden nur die Ordner synchronisiert, die tatsächlich kopiert werden müssen, sodass die Kernsysteme auf dem Zielserver unangetastet bleiben. Zugangsdaten für die Ziel-Datenbank werden AES-256-verschlüsselt gespeichert und tauchen nie in Logs oder Prozesslisten auf.
Willst Du vorher sehen, was ein Deployment tun würde? Starte es im Probelauf-Modus – es ändert sich nichts, bis Du bereit bist. Jeder Schritt wird live im Admin protokolliert, sodass Du immer genau weißt, was gerade passiert und wann es fertig ist.
Für Agenturen und Shop-Betreiber
Unbegrenzte Staging-Umgebungen parallel, vollständiges Synchronisationsprotokoll, Preflight-Checks vor jedem Remote-Deploy und alle Aktionen auch per Kommandozeile oder Cronjob automatisierbar. Passwörter und Zugangsdaten werden verschlüsselt gespeichert, sensible API-Keys können automatisch geleert oder entfernt werden.
⭐️ Gefällt Dir das Plugin?
Dann freuen wir uns über Deine Bewertung im Store!
Installationsservice
Sie möchten unser Plugin nutzen, haben aber keine Zeit für die Installation und Konfiguration? Wir helfen Ihnen gerne weiter! Unsere erfahrenen Mitarbeiter richten das Plugin direkt in Ihrem Shop ein, damit Sie sich auf Ihr Kerngeschäft konzentrieren können.
Einmalige Einrichtungsgebühr: 150 € (zzgl. gesetzlicher MwSt.)
Support
Wenn Du Fragen hast, kannst Du uns jederzeit kontaktieren – wir helfen Dir gerne!
✉ E-Mail:support@8mylez.com
✆ Telefon: +49 (0) 5251 284 710
Staging Umgebung – Sicher testen, bevor es live geht
Änderungen am Shop testen, ohne den laufenden Betrieb zu gefährden – das ist der Kern des Staging Umgebung Plugins. Mit wenigen Klicks direkt aus dem Shopware-Backend erstellst du eine vollständige Testkopie deines Shops: Dateien, Medien und Datenbank werden automatisch übertragen. Kein zweiter Server notwendig, kein technisches Vorwissen erforderlich.
Ob Plugin-Updates, Theme-Änderungen, neue Inhalte oder Shopware-Updates – alles wird zuerst in der Testumgebung geprüft. Erst wenn alles funktioniert, geht es live. Dein Shop läuft dabei völlig ungestört weiter.
DSGVO-konform und sicher
Kundendaten, Bestellungen und Newsletter-Empfänger können per Schalter automatisch vom Kopiervorgang ausgeschlossen werden. Der Mailversand wird im Staging automatisch deaktiviert – versehentliche Mails an echte Kunden sind damit ausgeschlossen. Zahlungen werden automatisch in den Testmodus gesetzt. Eine auffällige rote Leiste zeigt jederzeit klar an, ob du gerade im Testsystem oder im Live-Shop arbeitest.
Drei Sync-Modi für jedes Hosting-Setup
Je nach Infrastruktur wählst du den passenden Modus: Die lokale Kopie erstellt das Staging im Unterverzeichnis auf demselben Server – schnell und ohne zweiten Host. Für dedizierte Staging-Server steht der Server-zu-Server-Modus per SSH/rsync zur Verfügung. Teams mit eigenem Deployment-Repository nutzen den Git-basierten Modus, bei dem das Shop-Gerüst per Git-Checkout eingerichtet und Plugins sowie Assets per rsync übertragen werden.
Server-zu-Server-Deployment
Produktion und Staging müssen nicht mehr auf demselben Server liegen. Läuft Deine Testumgebung auf einem komplett anderen Host — ein gängiges Setup bei Managed- oder Shared-Hosting —, deployt das Plugin vollständig per SSH: Dateien und Datenbank werden sicher übertragen und automatisch synchron gehalten, ohne dass jemals eine direkte Verbindung zwischen den beiden Servern geöffnet werden muss.
Jedes Deployment startet mit automatisierten Preflight-Checks, die Fehlkonfigurationen erkennen, bevor überhaupt etwas angefasst wird — inklusive einer harten Sperre gegen versehentliches Überschreiben Deines Live-Shops. Es werden nur die Ordner synchronisiert, die tatsächlich kopiert werden müssen, sodass die Kernsysteme auf dem Zielserver unangetastet bleiben. Zugangsdaten für die Ziel-Datenbank werden AES-256-verschlüsselt gespeichert und tauchen nie in Logs oder Prozesslisten auf.
Willst Du vorher sehen, was ein Deployment tun würde? Starte es im Probelauf-Modus – es ändert sich nichts, bis Du bereit bist. Jeder Schritt wird live im Admin protokolliert, sodass Du immer genau weißt, was gerade passiert und wann es fertig ist.
Für Agenturen und Shop-Betreiber
Unbegrenzte Staging-Umgebungen parallel, vollständiges Synchronisationsprotokoll, Preflight-Checks vor jedem Remote-Deploy und alle Aktionen auch per Kommandozeile oder Cronjob automatisierbar. Passwörter und Zugangsdaten werden verschlüsselt gespeichert, sensible API-Keys können automatisch geleert oder entfernt werden.
⭐️ Gefällt Dir das Plugin?
Dann freuen wir uns über Deine Bewertung im Store!
Installationsservice
Sie möchten unser Plugin nutzen, haben aber keine Zeit für die Installation und Konfiguration? Wir helfen Ihnen gerne weiter! Unsere erfahrenen Mitarbeiter richten das Plugin direkt in Ihrem Shop ein, damit Sie sich auf Ihr Kerngeschäft konzentrieren können.
Einmalige Einrichtungsgebühr: 150 € (zzgl. gesetzlicher MwSt.)
Support
Wenn Du Fragen hast, kannst Du uns jederzeit kontaktieren – wir helfen Dir gerne!
✉ E-Mail:support@8mylez.com
✆ Telefon: +49 (0) 5251 284 710
Details
- Verfügbar in: Englisch, Deutsch
- Zuletzt aktualisiert: 22. Oktober 2026
- Veröffentlicht: 27. August 2020
- Version: 1.12.0
- Kategorie: Administration
Ressourcen
Bewertungen (22)
Durchschnittliche Bewertung von 4.14 von 5 Sternen
Top Plugin für faule Webentwickler
Durchschnittliche Bewertung von 5 von 5 Sternen
Als Verbesserungsvorschlag habe ich noch:
- Datenbank Klonen dauert sehr lang -> vllt. hier eine Übersicht wie der Fortschritt ist
- Wenn eine Datenbanktabelle größer ist, als der Arbeitsspeicher bricht die Migration ab
- Automatisches setzen eines Symlinks im public Ordner des Live Systems
- Automatisches Erstellen und Verwalten vom Verzeichnisschutz
Viele Grüße aus Paderborn!
Nützliches Plugin - erleichtert die Shoperstellung sehr!
Durchschnittliche Bewertung von 5 von 5 Sternen
Über den Extension Partner
8mylez
Partner Status
-
Shopware
Platinum Partner -
Shopware
Extension Partner
Details
-
Ø-Bewertung:
4.6
Durchschnittliche Bewertung von 4.6 von 5 Sternen
- Partner seit: 2015
- Erweiterungen: 50
- Zertifizierungen: 48
Support
- Land: Germany
- Spricht: Deutsch, Englisch
- Reaktionszeit: Schnell
Zur ausführlichen Dokumentation
Installation
- Shopware-Backend öffnen und zu Einstellungen → System → Plugins navigieren
- Plugin hochladen, installieren und aktivieren
- Cache leeren und neu anmelden
Staging-Umgebung anlegen
Navigiere zu Erweiterungen → Staging Umgebungen → Umgebungen und klicke auf „Staging Umgebung erstellen"
Grundeinstellungen
Name
Interne Bezeichnung der Staging-Umgebung. Der Name dient ausschließlich zur Unterscheidung innerhalb der Administration und wird nicht in der Storefront angezeigt.
Sync-Modus
Legt fest, wie und wo die Staging-Umgebung erstellt wird. Es stehen drei Optionen zur Verfügung:
Lokale Kopie (gleicher Server)
Das Staging-System wird im Unterverzeichnis des Live-Shops oder unter einem benutzerdefinierten Serverpfad angelegt. Die Umgebung ist anschließend standardmäßig über die bestehende Shop-URL mit angehängtem Verzeichnis erreichbar, beispielsweise meinshop.de/staging.
Server-zu-Server (komplette Kopie)
Die vollständige Shopware-Installation wird per SSH/rsync auf einen separaten Server übertragen. Geeignet für Staging-Systeme auf eigenem Server ohne Git-Deployment.
Server-zu-Server (Git-Repository)
Das Shop-Gerüst wird per Git-Checkout auf dem Zielserver eingerichtet, Plugins und Assets werden per rsync übertragen. Geeignet für Teams mit eigenem Deployment-Repository.
Verzeichnisname
Name des Verzeichnisses, in dem das Staging-System erstellt wird. Nur Buchstaben und Zahlen erlaubt, keine Leerzeichen oder Sonderzeichen, z.B. staging.
Unterverzeichnis
Falls Shopware in einem Unterverzeichnis installiert ist, diesen hier angeben, damit die Domains der Verkaufskanäle korrekt angepasst werden können.
Kommentar
Optionales Kommentarfeld für interne Informationen zur Staging-Konfiguration, z.B. Einsatzzweck oder Besonderheiten der Umgebung.
Ausgeschlossene Verzeichnisse
Verzeichnisse, die von der Übertragung ausgeschlossen werden sollen, z.B. große Media-Ordner. Kommagetrennt angeben, z.B. public/media, documents/files.
Staging-URL konfigurieren
Im Expertenmodus können folgende URL-Einstellungen vorgenommen werden:
Eigene Staging-Domain
Ermöglicht die Verwendung einer separaten Domain oder Subdomain für das Staging-System, z.B. staging.meinshop.de.
Wildcard-/Lizenz-Domain
Domain, unter der Shopware-Lizenzen und die Shop-ID im Staging laufen, z.B. *.meinshop.de. Im Remote-Modus Pflichtfeld.
Domain-Mappings
Legt für jede bestehende Verkaufskanal-Domain fest, unter welcher URL diese im Staging-System erreichbar sein soll. Dadurch kann für jede Verkaufskanal-Domain eine eigene Staging-URL hinterlegt werden.
Datenbank konfigurieren
Datenbank-Host
Host des Datenbankservers der Staging-Datenbank. Befindet sich die Datenbank auf demselben Server, kann 127.0.0.1 verwendet werden.
Datenbank-Port
Port des Datenbankservers, standardmäßig 3306.
Datenbank-Name
Name der Datenbank für das Staging-System.
Datenbank-Benutzer / Passwort
Zugangsdaten für die Staging-Datenbank. Das Passwort wird verschlüsselt gespeichert.
Datenbankverbindung testen
Prüft, ob mit den eingetragenen Zugangsdaten erfolgreich eine Verbindung zur Staging-Datenbank hergestellt werden kann.
Sicherheits- und Schutzeinstellungen
Mailversand ausschalten
Deaktiviert den E-Mail-Versand innerhalb des Staging-Systems. Dadurch wird verhindert, dass während Tests versehentlich Bestellbestätigungen oder andere Nachrichten an echte Empfänger versendet werden.
PayPal-Sandbox aktivieren
Schaltet PayPal automatisch in den Testmodus – über alle Verkaufskanäle, damit keine Live-Zahlungen vom Staging ausgelöst werden.
DSGVO-relevante Tabellen ausschließen
Schließt alle Datenbanktabellen mit personenbezogenen Daten vom Kopiervorgang aus, z.B. Kundendaten, Bestellungen, Newsletter-Empfänger und Warenkörbe.
Wartungsmodus
Versetzt das Staging-System nach der Erstellung in den Shopware-Wartungsmodus. Die Storefront ist dann nur für freigegebene IP-Adressen erreichbar.
Datenbanktabellen ausschließen
Zusätzliche Tabellen, deren Inhalte nicht in das Staging-System übernommen werden sollen, manuell auswählen.
Backendnutzer
Legt fest, welche Admin-Benutzer des Live-Shops in der Staging-Umgebung verfügbar sein sollen. Empfehlung: Nur das interne Kernteam auswählen.
Sensible Zugangsdaten bereinigen
Werte leeren
Der Konfigurationsschlüssel bleibt erhalten, der Wert wird geleert, z.B. PayPal-Live-Keys, Adyen, Klaviyo.
Einträge löschen
Der Konfigurationsschlüssel wird vollständig aus dem Staging-System entfernt.
Externe Services (Expertenmodus)
Falls der Live-Shop externe Services wie Redis, RabbitMQ oder Elasticsearch/OpenSearch nutzt, können hier separate Verbindungsdaten für das Staging-System hinterlegt werden:
- RabbitMQ Connection String – verhindert, dass Staging und Live dieselbe Queue nutzen
- Redis Connection String – verhindert gemeinsame Session- und Cache-Daten
- Elasticsearch/OpenSearch URL & Index-Prefix – eigener Suchindex für das Staging
SSH-Hosts (Server-zu-Server)
Für Remote-Deploys muss ein SSH-Zielserver hinterlegt werden:
- Name – Anzeigename des Servers
- Login – Format user@host:port
- SSH-Identity-File – Absoluter Pfad zum privaten SSH-Schlüssel auf dem Production-Server
- Verbindung testen – Prüft, ob die SSH-Verbindung erfolgreich hergestellt werden kann
Staging-Umgebung erstellen
Nach Abschluss der Konfiguration auf „Speichern" klicken. Anschließend über „Start" die Erstellung starten. Dabei werden Shop-Dateien und Datenbank entsprechend der vorgenommenen Einstellungen in die Staging-Umgebung übertragen. Je nach Shopgröße kann dieser Vorgang einige Minuten dauern.
Einzelne Schritte können auch separat ausgeführt werden:
- Dateien – nur Dateisynchronisation
- Datenbank – nur Datenbankabgleich
- Einstellungen – nur Konfigurationsanpassungen
Staging-Umgebung zurücksetzen oder löschen
Datenbank leeren
Entfernt alle Tabellen und Inhalte aus der konfigurierten Staging-Datenbank. Das Staging-System ist anschließend nicht mehr funktionsfähig, bis es erneut erstellt wird.
Dateien entfernen
Löscht alle Dateien aus dem konfigurierten Staging-Verzeichnis. Dieser Vorgang ist nicht umkehrbar.
Umgebung löschen
Entfernt den Eintrag aus der Administration. Das Plugin versucht dabei automatisch, Dateien und Datenbank zu bereinigen.
Protokoll
Unter Erweiterungen → Staging Umgebungen → Protokoll sind alle Synchronisationsvorgänge mit Zeitstempel und Statusmeldungen einsehbar. Protokolle können exportiert oder gelöscht werden.
1.12.0 6.7.0.0 - 6.7.15.1
A staging environment now only runs while the plugin is active in the live shop it was created from. Nothing is ever deleted.
1.11.6 6.7.0.0 - 6.7.15.1
Umlauts survive a database sync onto a server whose default charset is latin1.
1.11.5 6.7.0.0 - 6.7.15.1
A sync or deploy that runs longer than the message queue's acknowledgement timeout no longer starts over after every pass.
1.11.4 6.7.0.0 - 6.7.15.1
The file sync keeps symlinks and listens to its own switch again, and the staging URL no longer points at a leftover test domain.
1.11.3 6.7.0.0 - 6.7.15.1
Table excludes now take effect on the server-to-server deploy.
1.11.2 6.7.0.0 - 6.7.15.1
Staging isolation: a staging no longer reaches into the production installation.
1.11.1 6.7.0.0 - 6.7.15.1
1.11.0 6.7.0.0 - 6.7.15.1
Hardening and bugfix pass over the server-to-server (remote) deploy path, plus admin fixes.
1.10.8 6.7.0.0 - 6.7.15.1
1.10.7 6.7.0.0 - 6.7.15.1
Server-to-server staging: full remote sync, Git-based deploys, and a hardening pass over the remote deploy path.
1.10.6 6.7.0.0 - 6.7.15.1
- Fix cache:clear failed: Could not open input file: bin/console after a successful remote_dump deploy: the rsync invocation in RsyncDeployer::deploy combined a --include-whitelist (/custom/apps, /custom/plugins, /public) with --exclude=* AND --delete-excluded — that doesn't mean "delete what no longer exists in the whitelisted dirs", it means "delete everything on the target that is not in the whitelist". The first deploy therefore wiped bin/, vendor/, src/, config/, var/, composer.json and .env* on the staging server, leaving only custom/apps, custom/plugins and public. The subsequent bin/console cache:clear step then crashed because the binary was gone. Removed --delete-excluded; plain --delete still removes files that no longer exist on production inside the whitelisted directories, which is what was actually intended
1.10.5 6.7.0.0 - 6.7.15.1
- Fix post-import SQL crashing with ERROR 1146 (42S02) Table 'db.dead_message' doesn't exist on Shopware 6.5+ databases: the unconditional TRUNCATE TABLE dead_message; references a Symfony Messenger table that was removed in Shopware 6.5 (replaced by messenger_messages). Both truncates are now wrapped in information_schema-conditional dynamic SQL so the deploy doesn't crash when a particular table is missing — messenger_messages is always truncated on a fresh 6.7 install, dead_message only on legacy databases that still carry it
1.10.4 6.7.0.0 - 6.7.15.1
- Fix ERROR 1227 (42000) Access denied; you need (at least one of) the SUPER or SET_USER_ID privilege(s) during the dump import on the staging server: every mysqldump from a production database with stored routines, triggers, views or events embeds DEFINER= clauses that the target server only accepts from a SUPER-privileged user — typical managed MySQL / shared-hosting setups don't grant SUPER. RemoteDatabaseImporter::applyDomainReplacements now strips DEFINER clauses (both the /*!50017 DEFINER=...*/ and the plain DEFINER=user@host`` forms, plus the SQL SECURITY DEFINER qualifier) before piping the dump into mysql on the target, so the target server falls back to the current connection user as DEFINER. Also adds set -o pipefail to the gunzip/sed pipeline so a failing step can't silently produce an empty intermediate file
1.10.3 6.7.0.0 - 6.7.15.1
- Fix mysqldump: [ERROR] unknown variable 'net-write-timeout=600' aborting every remote_dump against MySQL 8.0+: --net-write-timeout and --net-read-timeout are session variables for the mysql server and the mysql client but were never valid mysqldump options — MySQL ≤ 5.7 silently accepted them, 8.0 errors out. Removed both flags; the outer 4 h process timeout (DEFAULT_TIMEOUT_SECONDS) is the real safety net for a stalled dump
1.10.2 6.7.0.0 - 6.7.15.1
- Declare shopware/storefront: ~6.7.0 as a composer dependency — the StagingBarSubscriber introduced in 1.9.3 listens to StorefrontRenderEvent from that package, but without the explicit require the Shopware Store's PHPStan run cannot resolve the symbol and emits Class Shopware\Storefront\Event\StorefrontRenderEvent was not found while trying to analyse it
- Fix silent mysqldump failures during remote_dump: the production-side dump piped mysqldump | gzip > file without set -o pipefail, so bash returned the exit code of gzip (always 0) even when mysqldump failed with a privilege / connection / lock error. The result was a 20-byte gzip-header-only "dump" that imported as an empty schema and then crashed the post-import SQL with Table 'db.dead_message' doesn't exist. The dump shell now starts with set -o pipefail, and RemoteDatabaseImporter::dumpProduction enforces a 1 KB minimum gz-size floor + a gunzip -t integrity check before SCP-transferring the dump — a missing PROCESS/SELECT/LOCK TABLES privilege or any other mysqldump failure now aborts the deploy with a clear message instead of silently wiping the staging schema
1.10.1 6.7.0.0 - 6.7.15.1
- Fix TypeError on first request after install when the emz_remote_deploy Monolog channel is not registered: constructors of ProcessSshClient, RemoteDeploymentService, and RemoteDeployHandler now accept a nullable LoggerInterface and fall back to NullLogger — the previous promoted-property default never fired because the DI container injected an explicit null (services.xml uses on-invalid="null"), bypassing the parameter default
- Auto-register the emz_remote_deploy Monolog channel and rotating-file handler via prependExtensionConfig in the plugin bootstrap — Shopware does not auto-load Resources/config/packages/*.yaml from plugins, so the channel was previously never created and the file under var/log/emz_remote_deploy.log was missing
- Fix MySQL server has gone away (SQLSTATE[HY000] 2006) at the end of a remote deploy: the long-running rsync/mysqldump/scp/import steps let the production MySQL wait_timeout close the connection underneath the PHP process, so the very first DB write after a step (emz_pse_log insert, emz_pse_environment progress update) failed and aborted the deploy. Introduces ConnectionGuard::ensureAlive() which is invoked before each post-step DB access in RemoteDeploymentService::runStep() and in LogServiceProgressReporter::report()/setProgress(), transparently reconnecting on a dead socket
- Fix admin save dialog blocking remote_dump environments: the front-end onClickSave always called the validate_db endpoint which opens a direct pdo_mysql connection to the target DB. For remote_dump the target DB lives on the staging server (typically reachable only via 127.0.0.1 on that host through SSH) and cannot be opened from production, so the save dialog stayed stuck on dbConnectionError. Validation is now skipped when syncMode === 'remote_dump' — the SSH-based preflight covers this case before the actual deploy
- Add remoteHostId single-select to the environment-detail form (under the remote_dump card) — the field is required for remote_dump but was previously not editable in the admin UI, forcing operators to write the FK via SQL
- Add dedicated SSH-Hosts admin module (list + create/edit) with new fields name (display label, defaults to login on migration), description, sshIdentityFile (per-host SSH key path that overrides the container-level default), and sshPort — previously the only field was login and CRUD was only possible via direct SQL
- RemoteDeploymentService::buildTargetFromEnvironment now prefers $host->getSshIdentityFile() over the container-level $defaultIdentityFile so different staging targets can use different SSH keys (one key per customer)
- Migration Migration1763000000StagingEnvironment13HostFields adds the four new columns to emz_pse_host and back-fills name from login for pre-existing rows
1.10.0 6.7.0.0 - 6.7.15.1
- Architecture refactoring (round 2 — Interface-Hygiene)
- Extract SafetyCheckerInterface, RemoteDeploymentServiceInterface; both implementations are now final and decoratable via DI alias
- All consumers (Controller, Handler, 6 Console-Commands) hang at RemoteDeploymentServiceInterface
- Context is now propagated into buildTargetFromEnvironment (was hard-coded Context::createDefaultContext() — closes potential ACL bypass during host lookup)
- Remove dead urlOverride field from RemoteDeployOptions, RemoteDeploy message, controller dispatch, commands, and frontend API service (was never read by any service implementation)
- Drop duplicated hasFailingCheck() helper in orchestrator — SafetyCheckerInterface::hasAnyFailure() is the single source of truth
- SshTarget::fromLogin accepts IPv6 hosts in user@[2001:db8::1]:port form, validates via FILTER_VALIDATE_IP; userAtHost() brackets v6 addresses for SCP/rsync compatibility
- SSH ControlPath enforces a %C/%h/%p/%r uniqueness token even for custom paths to prevent cross-target socket collisions
- ProcessSshClient::rsync/copyTo/copyFrom now log to the dedicated emz_remote_deploy channel (was missing — rsync errors were invisible)
- RollbackTargetCommand follows the same --defaults-extra-file password handling as the other DB clients (was the last MYSQL_PWD= leak)
- AbstractRemoteDumpCommand accepts UUID strings with dashes in --env=
- Architecture refactoring (round 1)
- Extract RsyncDeployerInterface, RemoteDatabaseImporterInterface, PostImportConfiguratorInterface, RemotePostSetupInterface; sub-services are now final and decoratable via DI aliases
- ProgressReporter is passed as method argument (no more setter on the interfaces, no more instanceof leak in sub-services); setProgress is part of the interface
- SSH ControlMaster opt-in (default on), ControlPath defaults to sys_get_temp_dir()/emz_pse_cm_%C so a writable ~/.ssh is no longer required
- mysql import / post-import SQL pass the password via base64 + 0600 .cnf file, never on the command line — eliminates leaks via /proc//cmdline and the SSH-debug-log
- Mailer DSN is transported as base64 in the bash invocation, killing $VAR/backtick expansion attacks
- Test-suite migrated from anonymous subclasses to dedicated Fake* test doubles (FakeRsyncDeployer, FakeDatabaseImporter, FakePostImportConfigurator, FakeRemotePostSetup); behavior-oriented test names
- Add new remote_dump sync mode for server-to-server staging deployments
- rsync (whitelist custom/apps, custom/plugins, public) from production to target
- mysqldump on production with --single-transaction --quick --hex-blob for consistent, low-impact dumps
- SCP transfer of the gzipped dump
- mysql < import on the remote target (no slow tunnel-based INSERT loop)
- Post-import SQL: license host, secret cleanup (clear / delete), domain replacements (with //host-anchored boundary match), mailer/PayPal flags, message-queue truncation
- Remote .env.local MAILER_DSN override (default null://null) — script is sent via streamStdin, DSN passed as quoted argument (no shell-interpolation)
- Remote bin/console cache:clear
- Granular progress reporter writes step logs into emz_pse_log and updates dbProgress/filesProgress (5/25/45/70/95/100)
- Local + remote temp directories cleaned up via finally-blocks even if a step fails
- Add 6 console commands under emzpse:remote-dump:* (preflight, test-connection, files, database, run, rollback-target) with dry-run as default
- Add admin UI: sync-mode selector, target-server card, sensitive-data card with PayPal / Adyen / Klaviyo / Mailer presets, optional custom overrides repeater (expert mode)
- Add live progress notifications during remote-dump deploys via /remote_deploy/progress polling endpoint with frontend deduplication by log id
- Add EnvironmentSecretEncoder (AES-256-GCM, key derived from APP_SECRET via HKDF, per-row IV, minimum APP_SECRET length 16 bytes) — production passwords are migrated automatically to target_db_password_encrypted on plugin update; the plain-text database_password field is cleared after re-encryption
- Add dedicated Monolog channel emz_remote_deploy with rotating-file handler under var/log/emz_remote_deploy.log (14 day retention) — ProcessSshClient writes structured debug logs of every SSH/SCP/rsync invocation with truncated stdout/stderr
- Security hardening
- SSH StrictHostKeyChecking=yes is the default for both ssh and scp (was accept-new); known_hosts must be pre-populated
- Path validation on targetShopwarePath and remote temp directories (absolute path required, no .. traversal, no control characters, / rejected outright in rsync target)
- mysqldump SQL identifier whitelist on rollback-target table names + backtick escaping
- sed pattern/replacement escaping uses dedicated sedEscapePattern / sedEscapeReplacement helpers (was preg_quote/addcslashes)
- Migration column-name whitelist (^[A-Za-z_][A-Za-z0-9_]*$) before any DDL
- dryRun request flag is parsed via filter_var(..., FILTER_VALIDATE_BOOL) (no more (bool)"false" === true)
- urlOverride request parameter validated for max length, control characters, and parseable host
- RemoteDeployHandler re-throws after logging so failed deploys end up in the messenger failure transport
- Throwable::__toString() (with full trace) no longer ends up in emz_pse_log description; only getMessage() is persisted
- Fix remote_host_id FkField referencing StagingEnvironmentLogDefinition instead of StagingEnvironmentHostDefinition
- Fix StagingEnvironmentEntity::getDirectory / buildCommand raising a clear RuntimeException when the remoteHost association is not loaded (was an undefined-method call)
- Add primary key on emz_pse_environment_user mapping table (with deduplication of pre-existing rows)
- Remove dead Services\Helper\HelperService container entry
- Add PHPUnit test suite (92 tests, ~91% line coverage on new code) with FakeSshClient / FakeProcessRunner test doubles, including controller, security-hardening and edge-case tests
1.9.4 6.7.0.0 - 6.7.15.1
- Fix Cannot delete or update a parent row (FK constraint 1451) when clearing a staging database with referential integrity by wrapping DROP TABLE with unsafeSqlWrapper
- Remove leftover debug echo of the dump command in DatabaseService::cloneDatabase
1.9.3 6.7.0.0 - 6.7.15.1
- Restore red staging topbar in storefront and administration (regression fix from 1.9.2)
- Restore STAGING_ENVIRONMENT=true flag in synced .env files
- Restore StagingBarSubscriber and is_staging_environment API endpoint
1.9.2 6.7.0.0 - 6.7.15.1
- Kompatibel mit Shopware 6.7
- Migration der Formularfelder im Admin-Bereich zur Vue-3-Bindungssyntax (v-model)
- Aktualisierung der Abhängigkeit von shopware/core auf ~6.7.0
1.9.0 6.7.0.0 - 6.7.15.1
- Hinweis Topbar in Storefront und Administration hinzugefuegt
- Postfix fuer Env Variable SHOPWARE_ES_INDEX_PREFIX hinzugefuegt
1.8.6 6.6.0.0 - 6.6.10.30
A staging environment now only runs while the plugin is active in the live shop it was created from. Nothing is ever deleted.
1.8.5 6.6.0.0 - 6.6.10.30
Umlauts survive a database sync onto a server whose default charset is latin1.
1.8.4 6.6.0.0 - 6.6.10.30
A sync or deploy that runs longer than the message queue's acknowledgement timeout no longer starts over after every pass.
1.8.3 6.6.0.0 - 6.6.10.30
The file sync keeps symlinks and listens to its own switch again, and the staging URL no longer points at a leftover test domain.
1.8.2 6.6.0.0 - 6.6.10.30
Ausgeschlossene Tabellen wirken jetzt auch beim Server-zu-Server-Deploy.
1.8.1 6.6.0.0 - 6.6.10.30
Staging-Isolation: Eine Staging greift nicht mehr in die Live-Installation hinein.
1.8.0 6.6.0.0 - 6.6.10.30
Backport für Shopware 6.6: kompletter Funktionsstand der 6.7-Linie 1.11.0 (Server-to-Server-Deploy: remote_dump/remote_full, Git-Deploy, verschlüsselte Secrets, SSH-Host-Verwaltung) portiert auf Shopware 6.6.
1.7.5 6.6.0.0 - 6.6.10.30
- Kompatibel mit Shopware 6.6
- Migration der Template-Slots in der Administration auf die Vue-3-Kurzschreibweise (#slot-name)
- Aktualisierung der Abhängigkeit shopware/core auf ~6.6.0
1.7.4 6.6.0.0 - 6.6.10.30
- Hinweis Topbar in Storefront und Administration hinzugefuegt
- Postfix fuer Env Variable SHOPWARE_ES_INDEX_PREFIX hinzugefuegt
1.7.3 6.6.0.0 - 6.6.10.30
- Bugfixing: Shop nicht erreichbar
1.7.1 6.6.0.0 - 6.6.10.30
- Checkbos Bug gefixt
1.7.0 6.6.0.0 - 6.6.10.30
- Kompatibilität für Shopware 6.6
1.6.13 6.5.0.0 - 6.5.8.19
- Fix getDirectory() missing a trailing slash for local staging environments: createSymlink() was symlinking the wrong path (.../stagingpublic/ instead of .../staging/public/) and changePermission() was chmod'ing a non-existent path (.../stagingconfig/jwt/*.pem), silently failing to tighten the JWT key permissions
- Fix the Storefront/Admin quick-access links missing a trailing slash: on shared hosting the stage lives in a webserver-aliased subfolder, and a request without the trailing slash could miss the alias before Shopware ever saw it
- Open the Storefront/Admin quick-access links on the staging environment detail page in a new tab
- Reset the cloned shop id (core.app.shopId/shopIdV2) unconditionally after sync instead of only when a license wildcard domain is set, so Shopware regenerates one bound to the staging APP_URL instead of throwing AppUrlChangeDetectedException once an app is installed
1.6.12 6.5.0.0 - 6.5.8.19
- Fix getDirectory() missing a trailing slash for local staging environments: createSymlink() was symlinking the wrong path (.../stagingpublic/ instead of .../staging/public/) and changePermission() was chmod'ing a non-existent path (.../stagingconfig/jwt/*.pem), silently failing to tighten the JWT key permissions
- Fix the Storefront/Admin quick-access links missing a trailing slash: on shared hosting the stage lives in a webserver-aliased subfolder, and a request without the trailing slash could miss the alias before Shopware ever saw it
- Open the Storefront/Admin quick-access links on the staging environment detail page in a new tab
- Reset the cloned shop id (core.app.shopId/shopIdV2) unconditionally after sync instead of only when a license wildcard domain is set, so Shopware regenerates one bound to the staging APP_URL instead of throwing AppUrlChangeDetectedException once an app is installed
1.6.11 6.5.0.0 - 6.5.8.19
- Fix webserver not being able to read the staging webroot on shared hosting after copying the environment (Apache AH00529 / 403): align the stage public/ tree's group with the live webroot's group, falling back to world-readable permissions if that's not possible (backported from 1.10.7)
- Fix changePermission() being called with a stale extra argument, a copy-paste bug in disableMailDelivery() that could target the wrong config row, and an SSH-tunnel host lookup that mishandled an unhydrated remote host
- Fix AddRemoteHostCommand's keypair-creation prompt: ssh-keygen ran regardless of the confirmation answer
- Fix a possible crash in LogService::getLastSync() when a log's stored description isn't valid JSON
- Remove dead domain-matching code and other unused methods; clean up docblocks
- Fix missing shopware/storefront composer dependency (used by StagingBarSubscriber, but never declared)
1.6.10 6.5.0.0 - 6.5.8.19
- Kompatibel mit Shopware 6.5
- Anpassung der Shopware/Core-Abhängigkeit auf ~6.5.0
1.6.9 6.5.0.0 - 6.5.8.19
SalesChannel Domain Mapping hinzugefuegt
1.6.6 6.5.0.0 - 6.5.8.19
- RabbitMQ und Elasticsearch Konfiguration kann fuer die Staging Umgebung gesetzt werden -> sofern im Einsatz
1.6.5 6.5.0.0 - 6.5.8.19
- Experten Modus mit neuen Einstellungsmoeglichkeiten
1.6.4 6.5.0.0 - 6.6.10.30
- Bugfixing: Shop nicht erreichbar
1.6.2 6.5.0.0 - 6.6.10.30
- Datenbank Bugfixes
1.6.1 6.5.0.0 - 6.7.15.1
- Hotfix: resolve critical error introduced in 1.6.1
1.6.0 6.5.0.0 - 6.5.8.19
- Neue Konsolenbefehle hinzugefügt
- Die Umgebungssynchronisierung erfolgt über die Warteschlange
- Fortschrittsbalken für die Synchronisierung hinzugefügt
- Links/Buttons zur Storefront und zur Administrator der Umgebung hinzugefügt
- Logs hinzugefügt
- Automatische Aktivierung der Paypal-Sandbox
- Auswahl von Benutzern hinzugefügt, die in die Umgebung einbezogen werden sollen
- UI/UX-Verbesserungen
1.5.3 6.5.0.0 - 6.5.8.19
Fügt die .env.local hinzu, was beim Fehlen zu Fehlern führte
1.5.2 6.5.0.0 - 6.5.8.19
- Fix fuer Update Config Service
1.5.1 6.5.0.0 - 6.5.8.19
Kompilierungsfehler während der Dateisynchronisierung behoben
1.4.4 6.5.0.0 - 6.5.8.19
- Kompatibel für View-Datenbanktabellen in DatabaseSyncService
- Möglichkeit ein Datenbanklimit hinzuzufügen, um zu steuern, wie groß die zu verarbeiteten Datensätze sein sollen
- Einzelne Datenbanktabellen ausschließen
- Die Möglichkeit, sensible Daten (wie Kundendaten) gemäß DSGVO auszuschließen
- Symlink erstellen
- E-Mail-Versand optional zu deaktivieren
1.4.3 6.5.0.0 - 6.5.8.19
Kompatibilität mit 6.5
1.4.2 6.4.0.0 - 6.5.8.19
- Rechte für config/jwt/public.pem und private.pem erteilt
- Symlink von Staging public wird auf der Production public erstellt
1.4.1 6.4.0.0 - 6.4.20.2
- Fehler bei der Datenbanksynchronisation behoben
1.4.0 6.4.0.0 - 6.4.20.2
- Kompatibilitaet zu Shopware 6.4.7
- Menüposition zu Erweiterungen Subnavigation geändert
1.3.0 6.4.0.0 - 6.4.20.2
- Kompatibilitaet zu Shopware 6.4
1.2.1 6.2.0 - 6.3.5.4
- Konsolenbefehle aufgeteilt, damit die einzelnen Schritte auch einzeln ausgefuehrt werden koennen
1.2.0 6.2.0 - 6.3.5.4
- Konsolenbefehl fuer das Synchronisieren von Staging Umgebungen hinzugefuegt
1.1.0 6.2.0 - 6.3.5.4
- Eine Staging Umgebung kann nur geloescht werden, wenn auch die Datenbank und der Unterordner vorher entfernt wurden
1.0.0 6.2.0 - 6.3.5.4
- Erstveröffentlichung