Staging System / Testing System / Developement System
To accept the cookie and load the video press “Load video”.
To accept the cookie and load the video press “Load video”.
Video
Description
Highlights
- Create and manage as many test environments as you like from the Shopware administration panel
- Isolated copy of the live shop’s files and/or database
- No need to re-licence plugins
- Test configurations, plugins, themes, updates and customisations risk-free
- In a subdirectory or on a separate server – flexible for any hosting setup
Features
- Run an unlimited number of staging environments in parallel
- Automatically redirect shop addresses to staging URLs – custom app URLs and individual staging domains for each sales channel
- Synchronise files and the database with a single click – test the database connection before creation
- Local copy on the same server – no second host required
- Transfer the copy to a separate staging server
- Optionally exclude customer data, orders and newsletters
- Automatically disable email dispatch on the staging environment
- Automatically switch payments to test mode
- Automatically remove or clear sensitive login details
- Select which backend users are granted access to the staging environment
- Complete log of all synchronisation processes
- Test run before every synchronisation – without making any changes
- All actions can also be automated via the command line or a cron job
- Passwords and login details are stored in encrypted form
About the Extension
Staging Environment – Test Safely Before Going Live
Test changes to your shop without putting your live business at risk – that's the core of the Staging Environment plugin. With just a few clicks directly from the Shopware backend, you create a complete test copy of your shop: files, media and database are transferred automatically. No second server required, no technical expertise needed.
Whether plugin updates, theme changes, new content or Shopware updates – everything is tested in the staging environment first. Only when everything works does it go live. Your shop continues to run completely undisturbed throughout.
GDPR-Compliant and Secure
Customer data, orders and newsletter recipients can be automatically excluded from the copy process with a single toggle. Email delivery is automatically disabled in staging – accidental emails to real customers are therefore impossible. Payments are automatically switched to test mode. A prominent red bar always makes it clear whether you are working in the test system or the live shop.
Three Sync Modes for Every Hosting Setup
Choose the mode that fits your infrastructure: the local copy creates the staging environment in a subdirectory on the same server – fast and without a second host. For dedicated staging servers, server-to-server mode via SSH/rsync is available. Teams with their own deployment repository use the Git-based mode, where the shop framework is set up via Git checkout and plugins as well as assets are transferred via rsync.
Server-to-Server Deployment
Production and staging no longer need to be on the same server. If your test environment runs on a completely different host — a common setup with managed or shared hosting — the plugin deploys fully via SSH: files and database are transferred securely and kept automatically in sync, without ever opening a direct connection between the two servers.
Every deployment starts with automated preflight checks that detect misconfigurations before anything is touched — including a hard lock against accidentally overwriting your live shop. Only the folders that actually need to be copied are synchronised, so the core systems on the target server remain untouched. Credentials for the target database are stored with AES-256 encryption and never appear in logs or process lists.
Want to see what a deployment would do before committing? Run it in dry-run mode – nothing changes until you're ready. Every step is logged live in the admin, so you always know exactly what's happening and when it's done.
For Agencies and Shop Owners
Unlimited staging environments in parallel, a complete synchronisation log, preflight checks before every remote deployment, and all actions can be automated via command line or cron job. Passwords and credentials are stored encrypted, and sensitive API keys can be automatically cleared or removed.
⭐️ Enjoying the plugin?
We'd love it if you left us a review in the store!
Installation Service
Would you like to use our plugin but don't have time for installation and configuration? We're happy to help! Our experienced team will set up the plugin directly in your shop so you can focus on your core business.
One-time setup fee: €150 (plus applicable VAT)
Support
If you have any questions, feel free to contact us at any time – we're always happy to help!
✉ Email:support@8mylez.com
✆ Phone: +49 (0) 5251 284 710
Staging Environment – Test Safely Before Going Live
Test changes to your shop without putting your live business at risk – that's the core of the Staging Environment plugin. With just a few clicks directly from the Shopware backend, you create a complete test copy of your shop: files, media and database are transferred automatically. No second server required, no technical expertise needed.
Whether plugin updates, theme changes, new content or Shopware updates – everything is tested in the staging environment first. Only when everything works does it go live. Your shop continues to run completely undisturbed throughout.
GDPR-Compliant and Secure
Customer data, orders and newsletter recipients can be automatically excluded from the copy process with a single toggle. Email delivery is automatically disabled in staging – accidental emails to real customers are therefore impossible. Payments are automatically switched to test mode. A prominent red bar always makes it clear whether you are working in the test system or the live shop.
Three Sync Modes for Every Hosting Setup
Choose the mode that fits your infrastructure: the local copy creates the staging environment in a subdirectory on the same server – fast and without a second host. For dedicated staging servers, server-to-server mode via SSH/rsync is available. Teams with their own deployment repository use the Git-based mode, where the shop framework is set up via Git checkout and plugins as well as assets are transferred via rsync.
Server-to-Server Deployment
Production and staging no longer need to be on the same server. If your test environment runs on a completely different host — a common setup with managed or shared hosting — the plugin deploys fully via SSH: files and database are transferred securely and kept automatically in sync, without ever opening a direct connection between the two servers.
Every deployment starts with automated preflight checks that detect misconfigurations before anything is touched — including a hard lock against accidentally overwriting your live shop. Only the folders that actually need to be copied are synchronised, so the core systems on the target server remain untouched. Credentials for the target database are stored with AES-256 encryption and never appear in logs or process lists.
Want to see what a deployment would do before committing? Run it in dry-run mode – nothing changes until you're ready. Every step is logged live in the admin, so you always know exactly what's happening and when it's done.
For Agencies and Shop Owners
Unlimited staging environments in parallel, a complete synchronisation log, preflight checks before every remote deployment, and all actions can be automated via command line or cron job. Passwords and credentials are stored encrypted, and sensitive API keys can be automatically cleared or removed.
⭐️ Enjoying the plugin?
We'd love it if you left us a review in the store!
Installation Service
Would you like to use our plugin but don't have time for installation and configuration? We're happy to help! Our experienced team will set up the plugin directly in your shop so you can focus on your core business.
One-time setup fee: €150 (plus applicable VAT)
Support
If you have any questions, feel free to contact us at any time – we're always happy to help!
✉ Email:support@8mylez.com
✆ Phone: +49 (0) 5251 284 710
Details
- Available: English, German
- Latest update: 22 October 2026
- Publication date: 27 August 2020
- Version: 1.12.0
- Category: Administration
Resources
Reviews (22)
Average rating of 4.14 out of 5 stars
Top Plugin für faule Webentwickler
Average rating of 5 out of 5 stars
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!
Average rating of 5 out of 5 stars
About the Extension Partner
8mylez
Partner Status
-
Shopware
Platinum Partner -
Shopware
Extension Partner
Details
-
Ø-Rating:
4.6
Average rating of 4.6 out of 5 stars
- Partner since: 2015
- Extensions: 50
- Certifications: 48
Support
- Based in: Germany
- Speaks: German, English
- Response time: Quickly
Installation
- Open the Shopware backend and navigate to Settings → System → Plugins
- Upload, install and activate the plugin
- Clear the cache and log in again
Create a Staging Environment
Navigate to Extensions → Staging Environments → Environments and click "Create Staging Environment"
General Settings
Name
Internal name of the staging environment. The name is used exclusively for identification within the administration and is not displayed in the storefront.
Sync Mode
Defines how and where the staging environment is created. Three options are available:
Local Copy (same server)
The staging system is created in a subdirectory of the live shop or under a custom server path. By default, the environment is accessible via the existing shop URL with the directory appended, for example meinshop.de/staging.
Server-to-Server (full copy)
The complete Shopware installation is transferred to a separate server via SSH/rsync. Suitable for staging systems on a dedicated server without Git deployment.
Server-to-Server (Git repository)
The shop framework is set up on the target server via Git checkout, plugins and assets are transferred via rsync. Suitable for teams with their own deployment repository.
Directory Name
Name of the directory in which the staging system is created. Only letters and numbers are allowed, no spaces or special characters, e.g. staging.
Subdirectory
If Shopware is installed in a subdirectory, specify it here so that the sales channel domains can be adjusted correctly.
Comment
Optional comment field for internal information about the staging configuration, e.g. purpose or special characteristics of the environment.
Excluded Directories
Directories to be excluded from the transfer, e.g. large media folders. Enter comma-separated, e.g. public/media, documents/files.
Configure Staging URL
The following URL settings can be configured in expert mode:
Custom Staging Domain
Allows the use of a separate domain or subdomain for the staging system, e.g. staging.meinshop.de.
Wildcard / License Domain
Domain under which Shopware licenses and the shop ID run in staging, e.g. *.meinshop.de. Required field in remote mode.
Domain Mappings
Defines the URL under which each existing sales channel domain should be accessible in the staging system. A separate staging URL can be stored for each sales channel domain.
Configure Database
Database Host
Host of the staging database server. If the database is on the same server, 127.0.0.1 can be used.
Database Port
Port of the database server, default is 3306.
Database Name
Name of the database to be used for the staging system.
Database User / Password
Access credentials for the staging database. The password is stored encrypted.
Test Database Connection
Checks whether a connection to the staging database can be successfully established using the entered credentials.
Security Settings
Disable Mail Delivery
Disables email sending within the staging system. This prevents order confirmations or other messages from being accidentally sent to real recipients during testing.
Activate PayPal Sandbox
Automatically switches PayPal to test mode – across all sales channels, so that no live payments are triggered from the staging system.
Exclude GDPR-Relevant Tables
Excludes all database tables containing personal data from the copy process, e.g. customer data, orders, newsletter recipients and shopping carts.
Maintenance Mode
Puts the staging system into Shopware maintenance mode after creation. The storefront is then only accessible for approved IP addresses.
Exclude Database Tables
Manually select additional tables whose contents should not be transferred to the staging system.
Backend Users
Defines which admin users of the live shop should be available in the staging environment. Recommendation: Only select the internal core team.
Clean Up Sensitive Credentials
Clear Values
The configuration key is retained, but the value is cleared, e.g. PayPal live keys, Adyen, Klaviyo.
Delete Entries
The configuration key is completely removed from the staging system.
External Services (Expert Mode)
If the live shop uses external services such as Redis, RabbitMQ or Elasticsearch/OpenSearch, separate connection data for the staging system can be stored here:
- RabbitMQ Connection String – prevents staging and live from sharing the same queue
- Redis Connection String – prevents shared session and cache data
- Elasticsearch/OpenSearch URL & Index Prefix – dedicated search index for staging
SSH Hosts (Server-to-Server)
For remote deployments, an SSH target server must be stored:
- Name – display name of the server
- Login – format user@host:port
- SSH Identity File – absolute path to the private SSH key on the production server
- Test Connection – checks whether the SSH connection can be successfully established
Create Staging Environment
After completing the configuration, click "Save". Then start the creation process by clicking "Start". Shop files and database are transferred to the staging environment according to the settings configured. Depending on the shop size, this process may take several minutes.
Individual steps can also be executed separately:
- Files – file synchronisation only
- Database – database sync only
- Settings – configuration adjustments only
Reset or Delete Staging Environment
Clear Database
Removes all tables and contents from the configured staging database. The staging system will no longer be functional until it is recreated.
Remove Files
Deletes all files from the configured staging directory. This process cannot be undone.
Delete Environment
Removes the entry from the administration. The plugin automatically attempts to clean up files and database.
Log
Under Extensions → Staging Environments → Log all synchronisation processes can be viewed with timestamps and status messages. Logs can be exported or deleted.
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
- Compatible for Shopware 6.7
- Migrate administration form fields to Vue 3 binding syntax (v-model)
- Bump shopware/core dependency to ~6.7.0
1.9.0 6.7.0.0 - 6.7.15.1
- Add hint topbar in storefront and administration
- Add postfix for env variable SHOPWARE_ES_INDEX_PREFIX
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
- Compatible for Shopware 6.6
- Migrate administration template slots to Vue 3 shorthand syntax (#slot-name)
- Bump shopware/core dependency to ~6.6.0
1.7.4 6.6.0.0 - 6.6.10.30
- Add hint topbar in storefront and administration
- Add postfix for env variable SHOPWARE_ES_INDEX_PREFIX
1.7.3 6.6.0.0 - 6.6.10.30
- Bugfixing: Shop not available
1.7.1 6.6.0.0 - 6.6.10.30
- fixed checkbox bug
1.7.0 6.6.0.0 - 6.6.10.30
- Added Shopware 6.5 Compatibility
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
- Compatible for Shopware 6.5
- Bump shopware/core dependency to ~6.5.0
1.6.9 6.5.0.0 - 6.5.8.19
Add SalesChannel Domain Mapping
1.6.6 6.5.0.0 - 6.5.8.19
- Configuration for RabbitMQ and Elasticsearch for the staging environment if in use
1.6.5 6.5.0.0 - 6.5.8.19
- Export mode with new configurations
1.6.4 6.5.0.0 - 6.6.10.30
- Bugfixing: Shop not available
1.6.2 6.5.0.0 - 6.6.10.30
- Database bug fixed
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
- add miscellaneous console commands
- Environment synchronization happens via queue
- add progressbars for synchronization
- add links to to storefront and admin of environment
- add Logs page
- add automatic activation of paypal sandbox
- add selection of users to be included in environment
- ui/ux-improvments
1.5.3 6.5.0.0 - 6.5.8.19
1.5.2 6.5.0.0 - 6.5.8.19
- Fix for Update Config Service
1.5.1 6.5.0.0 - 6.5.8.19
Fix compile error while file sync
1.4.4 6.5.0.0 - 6.5.8.19
- Compatible for view database columns in DatabaseSyncService
- Add database limit to increase synchronization
- Exclude individual database tables
- Add GDPR to remove all relevant customer data
- Symlink created
- Optionally deactivate email delivery
1.4.3 6.5.0.0 - 6.5.8.19
Compatibilty with 6.5
1.4.2 6.4.0.0 - 6.5.8.19
- Granted rights to config/jwt/public.pem and private.pem
- Symlink from Staging public is created on the Production public
1.4.1 6.4.0.0 - 6.4.20.2
- Fix database synchronization error
1.4.0 6.4.0.0 - 6.4.20.2
- Change menu position to extensions subnavigation
1.3.0 6.4.0.0 - 6.4.20.2
- Compatibility for Shopware 6.4
1.2.1 6.2.0 - 6.3.5.4
- Split the console commands, to run them individually
1.2.0 6.2.0 - 6.3.5.4
- Added console commands to sync existing staging environments
1.1.0 6.2.0 - 6.3.5.4
- A staging environment can only be deleted if the database and folder are empty
1.0.0 6.2.0 - 6.3.5.4
- First release in store