What gets copied What goes into the staging environment, and what stays out?
A build copies all files and all tables of the live shop, without the records created after the run began. Development folders and backups stay out; cache, logs, queue, carts and sessions start empty.
All files, with their time stamp.
Code, plugins, themes, media and configuration go into the staging environment as they are in the live shop. What does not come along is set in the plugin settings and applies to every staging environment.
var/cache, var/log, var/queue, var/lock. The folder is created with the permissions of the original and stays empty: Shopware wants the folder, not its content.
.git, .github, .idea, .vscode, node_modules. The staging folder and every staging environment with a path of its own always stay out.
install.lock and .env.local.php. The staging environment gets a .env of its own.
*.sql, *.sql.gz, *.zip, *.tar, *.tar.gz: backups lying in the shop folder do not move along.
Every table, the content per area.
The structure of every table always comes along in full. You decide per area which content is copied, on the page of the staging environment in the tab "Data". This is the default:
Default: With content Products, categories, sales channels, settings and everything the live shop cannot run without. Always come with content.
Default: With content Orders, carts and sessions need them: as long as one of these areas brings content, the customers come along too.
Default: With content Including invoices, deliveries and payments.
Default: With content
Default: With content
Default: Empty Open carts and the sessions of the storefront.
Default: Empty Links to reset passwords, access keys and login tokens.
Default: Empty Logs, notifications, counters, state histories and consents.
Default: Empty Messages and jobs the live shop still wants to process, including webhook logs. In the staging environment they would otherwise run a second time.
Default: Empty The change history of records.
Default: Empty Logs and files of import and export.
Additional tables, of plugins for instance, come with content by default; each can be left out on its own. The plugin's own tables arrive empty in the staging environment: it sees neither the other staging environments nor their runs and passwords.
Records created in the live shop after the run began stay out; "Data from" shows that point in time. The search index comes along so the search of the staging environment finds things right away. Personal data is replaced by the anonymization rule set before it arrives; PDF documents already generated come along as files, as they are.
They do not go into the staging environment. Whatever relies on them in the live shop is missing there; the preflight names them before the build.
Four buttons, four effects.
On the page of a staging environment the runs are grouped by what they do: "Changes the staging environment", "Only reads" and "Removes the staging environment".
Fetches only the database anew and sets the staging environment up again. Code, themes and media stay. The quick way when you only need fresh data.
Builds files and database completely anew. First the old copy is torn down: its database is emptied, the database itself stays, its files are deleted.
Removes the link in the web root and the files and empties the database. The settings stay, rebuilding works at any time.
Only a torn-down staging environment can be removed from the list completely, so no copy stays behind without an entry.
The plugin deletes only what carries the marking of this staging environment. If a rebuild finds foreign tables or the database of another staging environment, it stops without deleting anything.
What shop owners ask about it.
Do the orders come along?
Yes. Orders, documents, deliveries and payments come with content by default, so invoices, returns and reports can be tested. Names, addresses, mail addresses and phone numbers in the database are replaced by the rule set before they arrive in the copy. Documents already generated, such as invoice PDFs, are files and come along as they are.
What happens to changes in the staging environment when I refresh?
"Refresh data" copies only the database anew and sets the staging environment up again. What was changed in its database is gone afterwards; code, themes and media of the staging environment stay as they are. "Rebuild" also replaces the files.
Can I leave out single tables?
The structure of every table always comes along. You decide per area in the tab "Data" whether content is copied, each with the switch "Copy content". Tables of plugins outside the areas come with content and can be left out one by one.
Is the live shop slowed down while copying?
A run works in small slices and only reads the live shop. The slice size is set in the plugin settings under "Slice size in megabytes"; smaller slices spare a busy live shop, larger ones finish sooner.
More about the plugin
-
Setting up
The assistant in seven steps, the preflight and the first build.
-
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.
-
Comparison with the standard
What Shopware does itself with system:setup:staging and what the plugin adds.
-
Pricing
What a staging environment costs, monthly or yearly, and what each plan includes.