DataFirefly Staging Pro — Complete Guide

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.

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.
• Skip customer data: creates the customer, customer address, order, cart, message, guest, newsletter and GDPR log tables empty on the staging. Supplier, manufacturer and warehouse addresses are kept, as are the order configuration tables (states, message templates, return states, cart rules). See the dedicated section below.
• 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.

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.

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.

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.

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.

Staging without customer data

The Skip customer data option, available since version 1.1.0, creates the staging with no personal data at all. The tables concerned are created with their exact structure but stay empty. This is the recommended choice when handing a staging site to an external contractor, for a theme or module test that does not involve the checkout, and to reduce the GDPR footprint of your test environments.

What is not copied

• Customers, customer groups, support threads and messages, customer sessions, guests and connection statistics.
• Orders and the whole related family: details, history, invoices, payments, carriers, applied cart rules, credit slips and returns.
• Carts, cart products, wishlists, messages, newsletter subscriptions, GDPR logs and mail logs.
• Customer addresses: the address table is copied with a filter, only the rows attached to a customer are left out.

What is kept

• Supplier, manufacturer, warehouse and store addresses.
• Order configuration tables: order states and their translations, message templates, return states, credit slip types.
• Cart rules, vouchers, carriers, taxes and the entire catalogue.
• Back-office employees: you log in to the staging with your usual credentials.

HTTP authentication and cPanel / LiteSpeed hosts

Since version 1.0.1, the .htpasswd file is generated in APR1-MD5 format (the one produced by htpasswd -m), which Apache, LiteSpeed and nginx all read. Version 1.0.0 used bcrypt, which LiteSpeed (very common behind cPanel) cannot read: the staging then answered 404 on every page.

The protection block also adds an inline 401 error page. On cPanel, 401 errors are globally redirected to /401.shtml, a page that does not exist in PrestaShop: the sub-request falls into the production dispatcher and returns its 404 page, so the browser never shows the login prompt. The inline page bypasses that redirect.

Finally, the ErrorDocument 404 line of the copied .htaccess is rewritten to the staging subfolder: an error on the staging displays the staging’s 404 page, not the production one.

Self-check at creation

At the end of the configuration step, the module sends a HEAD request to the staging’s robots.txt, with the credentials when protection is enabled, then without credentials to check that the server answers 401. The result is written to the environment logs:

• 200 with credentials and 401 without: everything is fine.
• The server rejects the authentication block: the module removes the block and the .htpasswd, disables the option and shows “Ready with warning” on the environment row. The staging is then reachable without a password; enable maintenance mode.
• Code 0: the server cannot call itself (outgoing requests blocked). Open the staging URL manually.

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.

The staging answers 404 everywhere, or the login prompt never appears? This is the symptom fixed in 1.0.1 on cPanel / LiteSpeed hosts. Update the module and run a Refresh of the environment; see the “HTTP authentication and cPanel / LiteSpeed hosts” section above.

Can I create a staging without my customers’ data? Yes, tick “Skip customer data” at creation. See the “Staging without customer data” section above.

Version history

1.1.0 (4 September 2026)

• New “Skip customer data” option: customers, customer addresses, orders, carts, messages, guests, newsletter and GDPR logs created empty on the staging.
• Supplier, manufacturer and warehouse addresses kept, as well as the order configuration tables.
• Push safeguard: those tables are removed from the list and refused server-side on a staging created without customer data.

1.0.1 (3 September 2026)

• htpasswd protection: hash generated in APR1-MD5, supported by both Apache and LiteSpeed (bcrypt was rejected on some cPanel hosts, making the staging unreachable).
• HTTP login prompt: inline 401 page, for hosts that redirect 401 errors to a missing page.
• ErrorDocument line of the .htaccess rewritten to the staging subfolder.
• Self-check at the end of creation: HTTP check of the staging, automatic removal of the protection if the server rejects it, warning shown in the dashboard.

1.0.0 (11 June 2026)

First public release.