PS PrestaShop PrestaShop Intermediate

DataFirefly Staging Pro — Complete Guide

Clone, test and push to production: installation, creating a staging site, protection options, selective push and rollback for PrestaShop 8 and 9.

Updated Module version 1.0.0

Staging Pro creates a complete copy of your shop (files + database) in a protected subfolder of your current hosting, with no timeout thanks to its batch copy engine. You test modules, themes and updates safely, then push your changes back to production table by table, with automatic backup and one-click rollback. This guide covers installation, creating a staging site, protection options, pushing to production and rollback.

Installation

  1. Download the dfstagingpro.zip archive from your DataFirefly account.
  2. PrestaShop back office → Modules → Upload a module → send the ZIP.
  3. On installation, the module creates its df_staging_env and df_staging_log tables, registers its hooks and adds the Advanced Parameters → Staging Pro tab.

Compatible with PrestaShop 8.0 to 9.x. PHP must be able to write to the shop root (to create the staging subfolder) and the MySQL user must be able to CREATE, DROP and RENAME TABLE — which is the case in a standard PrestaShop installation. No Composer dependency.

How staging works

A staging environment is created in a subfolder at the root of your shop (for example /staging-v2/) and uses a dedicated table prefix (for example dfs1_) in the same database as production. You therefore need no second server, no new MySQL access and no DNS configuration.

The copy engine works in batches of a few seconds then hands back control, resuming exactly where it stopped: file copy via a persistent queue, database cloning in row chunks. A multi-gigabyte shop clones without errors, even on shared hosting with a low max_execution_time.

Creating a staging site

Go to Advanced Parameters → Staging Pro, then in the creation panel:

  1. Enter a name (lowercase letters, digits and hyphens only, for example v2). The staging URL will be your-shop.com/staging-v2/.
  2. Choose your protection and copy options (see below).
  3. Click Create. Progress is displayed live with a progress bar.

At the end of the process, the staging URL and, where applicable, the htpasswd credentials appear on the environment’s row.

Protection and copy options

  • Protect with .htpasswd: adds HTTP authentication (user staging). The password can be entered or auto-generated, then displayed on the dashboard.
  • Disable e-mails: turns off outgoing e-mails on the staging site (PS_MAIL_METHOD = 3). No risk of e-mailing a real customer.
  • Disable payments: disables and unhooks known payment modules on the staging site.
  • Skip statistics: excludes large, non-essential tables from the copy (connections, logs, abandoned carts…) for a much faster copy.
  • Symlink the img/ folder: creates a symbolic link to the images instead of copying them, for huge disk space savings.
  • Maintenance mode: puts the staging site in maintenance with your admin IP whitelisted.

From the moment it is created, every staging site automatically gets an X-Robots-Tag: noindex header, a noindex meta tag and a blocking robots.txt, as well as an orange STAGING banner on the front office and in the back office. Your test environments will not be indexed by Google.

The img/ symlink option shares the image folder with production: modifying or deleting an image on the staging side also affects the live shop. Reserve it for tests that do not touch images.

The batch copy engine

Creating a staging site chains several steps, each time-budgeted and resumed automatically: prepare, copy files, clone the database, rewrite URLs, configure and protect, then finalize. URL rewriting covers shop_url, the configuration (including serialized and JSON values, handled without corruption), as well as CMS content, products, categories, brands, suppliers and stores.

If the page is closed during creation, the environment stays in progress and automatically resumes the copy when the dashboard is reopened, exactly where it stopped.

Refresh, multi-environment and deletion

  • Refresh: rebuilds an existing staging site from the current production state (delete then recreate the folder and prefix), in one click.
  • Multi-environment: create as many staging sites as you need (v2, hotfix, module-test…), each independent.
  • Deletion: deletes an environment’s folder and tables in a budgeted way, with no timeout.

Pushing to production

Once your tests are validated, the Push button lets you send your changes back to production, table by table:

  1. Click Push on the environment’s row: the list of tables appears, with the row count of each one.
  2. Check exactly which tables to transfer.
  3. Confirm. Before each replacement, the corresponding production table is automatically backed up via a timestamped rename to a dfbak{timestamp}_ prefix.

URLs are rewritten in the staging → production direction during the transfer. Critical tables (shop_url, configuration, shop, sessions and module tables) are protected and can never be pushed.

The push modifies your live shop. The automatic backup protects the replaced tables, but always double-check your selection. Avoid pushing order or customer tables if production has continued to record sales since the staging site was created.

Rollback

The Rollback button restores production from the last push backup, in one click. The module renames the dfbak…_ backup tables back to their original place.

Once a push is validated and stable, delete the old dfbak* tables (via phpMyAdmin or any SQL client) to free up space in your database.

Safeguards and log

  • All actions are blocked if the current shop is itself a staging site, to avoid cascading operations.
  • A detailed log is available per environment via the Logs button.
  • Since a robots.txt in a subfolder is not honored by search engines, the real anti-indexing protection relies on the X-Robots-Tag header and the noindex meta tag; the .htpasswd option remains the safest protection.

Compatibility and technical notes

  • PrestaShop 8.0 to 9.x, compatible with shared hosting and multilingual.
  • Legacy admin controller (no Symfony controller) for PS8/PS9 compatibility.
  • Back-office AJAX endpoints via the 4th argument of getAdminLink(); JSON rendering through a dedicated method.
  • Staging = subfolder at the root + table prefix dfs{id}_ in the same MySQL database.
  • Timestamped push backups under the dfbak{YmdHis}_ prefix, to be purged after validation.

FAQ and troubleshooting

Does the module work on shared hosting? Yes. The batch copy engine with automatic resume avoids any timeout, whatever the server’s max_execution_time.

Creation was interrupted, what should I do? Reopen the Staging Pro dashboard: the environment automatically resumes the copy where it stopped.

Can the staging site send e-mails to my customers? Not if the “Disable e-mails” option is active (recommended): outgoing e-mails are turned off on the staging site.

After a push, how do I undo it? Use the Rollback button, which restores the last automatic backup. Then remember to purge the obsolete dfbak* tables.

Can I create several staging sites at the same time? Yes, the number of environments is unlimited and each one is fully independent.

Was this page helpful?

Still stuck? Contact support