Comparison What does Shopware do itself, and what does the plugin add?
Shopware ships the command system:setup:staging. It turns a finished copy into a test system with banner and mail lock. The copy itself you create by hand, with server access and a shell. Here both stand side by side, row by row.
One command for a finished copy.
bin/console system:setup:staging with the configuration config/packages/staging.yaml switches a copy that already runs to staging. The real work comes before: copying files, exporting and importing the database, adjusting the .env, pointing the web server at the copy. Access protection and anonymization are still missing afterwards.
The plugin takes over the way there and uses the same Shopware staging mode at the end. Banner and robots.txt are therefore the same as with the standard; mail delivery follows the setting "Mails" of the staging environment.
Shopware standard and staging plugin.
| Task | Shopware standard | Staging plugin |
|---|---|---|
| Creating the copy | ||
| Copy the shop's files | Not included, by hand with a shell or FTP. | In the administration, without .git, node_modules and backups; cache, logs and queue start empty. |
| Fill a second database | Not included, export and import by hand. | Table by table with the state at the start of the run, in small slices; the plugin creates the database itself if you want. |
| Address and .env of the copy | Sales channel domains by rules from staging.yaml; you write the .env yourself. | Own .env values, domains rewritten to the copy's address, own cache id. |
| Progress and interruption | Not included; an interrupted export starts over. | Run window with every step; an interrupted run continues where it stopped. |
| Setting up the copy | ||
| Staging mode with banner | Yes, with bin/console system:setup:staging in the finished copy. | Yes, the plugin sets Shopware's staging mode while setting up. |
| Emails from the copy | Delivery locked. | In the copy's mail archive, to a catch-all address, only to released addresses or to the real recipients. |
| Apps, webhooks and shop id | Apps with an app secret deleted, shop id discarded. | As in the standard (apps with an app server removed, new shop id), plus calls through the app and webhook clients blocked and logged. |
| Scheduled tasks | Not switched off. | Off as long as "Switch off scheduled tasks" is on, which is the default. |
| Search engines | robots.txt locks them out in staging mode. | robots.txt locks them out, plus "noindex, nofollow" on every page of the copy. |
| Data and access | ||
| Customer data in the copy | Stay as they are in the live shop. | Anonymized by rule set, adjustable per column, with preview and record. |
| Access protection | Not included. | Password page in front of storefront and administration, IP addresses without a password, direct link from the live shop. |
| Access for the agency | You create users in the copy yourself. | Default user only in the copy and "Show credentials" to pass on. |
| Operation | ||
| Several staging environments | Not included. | Per staging environment its own folder, database and settings. |
| Keeping the copy current | A new copy by hand. | "Refresh data", "Rebuild" and a schedule daily, weekly or monthly. |
| Differences to the live shop | Not included. | Comparison of extensions, settings, contents, files and database structure, each finding with its side. |
| Expiry date | Not included. | Lifetime with expiry date and a reminder before; after that the copy locks itself. |
| Copy on another server | Works, because you create the copy yourself wherever you like. | Yes, via SFTP on a second server. |
| Views, triggers and routines | Come along if you copy the database as a whole. | Do not come along; the preflight names them. |
What shop owners ask about it.
What exactly does system:setup:staging do?
Run in a finished copy, bin/console system:setup:staging switches mail delivery off, shows a banner in storefront and administration, rewrites the domains of the sales channels by the rules in config/packages/staging.yaml, deletes apps with an app secret and the shop id, deletes every consent, switches off configured extensions, sets configured system settings, stops if Elasticsearch indexes already exist, and marks the shop as staging; robots.txt then only answers Disallow: /.
Do I still have to run system:setup:staging with the plugin?
No. The plugin sets Shopware's staging mode itself while setting up the copy. That is why banner and robots.txt work in the copy even when the plugin is switched off there, and with "Send nothing" the mail lock as well. The plugin keeps its settings for the copy in config/packages/zz-dvsn-staging.yaml of the copy.
What does the standard leave to me?
The copy itself: copying the files, filling a second database, writing the .env, connecting the web server, protecting the copy from strangers and removing customer data. For that you need server access and a shell, and you do it again for every fresh copy.
Where does the standard go further than the plugin?
Views, triggers and routines come along when you copy the database as a whole yourself. The plugin copies table by table and leaves them out; the preflight names them before the build.
More about the plugin
-
Setting up
The assistant in seven steps, the preflight and the first build.
-
What gets copied
Which files and tables come along, what stays empty and how rebuilding, refreshing and tearing down work.
-
Anonymization
The rule set, the replacements per column, the preview and the record of every build.
-
Protection and access
Password page, IP addresses without a password, default user, credentials and maintenance mode.
-
Emails and calls
Four ways for emails, three for calls from apps and webhooks, plus scheduled tasks and analytics.
-
Services and plugins
Search, Redis, queue, reverse proxy and plugins: what the copy shares with the live shop.
-
Differences to the live shop
The comparison shows extensions, settings, content, files and database structure, each with its side.
-
Schedule and automation
Schedule, lifetime with reminder, Flow Builder and console commands.
-
Hosting and server
What gets written on the server, Apache, nginx, an address of its own, database privileges and SFTP.
-
Pricing
What a staging environment costs, monthly or yearly, and what each plan includes.