A test environment for PrestaShop: how to set up a copy that bothers nobody

Testing changes on a copy of the store before taking them to production is one of the most sensible things you can do. But a copy is, by definition, a complete store: it has the same customers, the same email configuration, the same gateway keys and the same scheduled tasks. If you do not disconnect it properly, it does exactly what the real store does, and that includes writing to your customers.

This article is a list of what needs to be neutralised in a test copy, in the order it is best done.

Where to set it up

There are three usual options, each with its advantages:

• Locally, on the developer's computer or on an internal server. It is the safest, because it cannot be reached from the Internet, but it is harder to share with whoever needs to review it.
• On a subdomain of the same hosting. It is convenient, but it shares the server with the real store: a heavy test (an import, an image regeneration) takes resources away from production.
• On a separate server, with the same PHP version and the same configuration as production. This is ideal for rehearsing updates, because environment differences will not mislead you.

Whichever you choose, the copy must have the same PHP version as the real store, unless a PHP change is precisely what you are testing.

Step 1: email comes first

Even before opening the copy in the browser, cut off email. A freshly imported copy has the production SMTP configuration and a database with real customers. An order status change, an abandoned cart that a module decides to remind about or a scheduled task that sends newsletters is enough to write to a real person from your test environment.

Options, from most to least recommended:

• Capture email with a test SMTP server that receives all messages and shows them in a web inbox without delivering them. That way you can check how the emails look without any risk.
• Disable sending in Advanced Parameters → E-mail, with the option to never send emails. It is quick, but it does not let you see the emails.

Step 2: anonymised personal data

A test copy does not need your customers' real names, emails, phone numbers and addresses. And having them in an environment less protected than production is a data protection risk. Replace, at the very least:

• Customer emails with fictitious addresses on a domain that does not exist or that you control.
• First names, surnames, phone numbers and addresses of customers and of shipping addresses.
• Customer messages, internal notes and company data such as the NIF (Spanish tax ID).
• Newsletter subscribers and any module table that stores personal data: forms, reviews, wish lists.

Keep the orders, amounts and products: they are what you need for testing. And change the employees' passwords to ones that differ from production.

Step 3: payments in test mode

Each gateway has a test mode with its own keys. On the copy, switch them all to that mode before placing the first order. Check in particular:

• Production keys of the gateway: replace them with the test ones; do not just tick a box if the module uses whatever keys it has stored.
• Webhooks and notifications: the real gateway keeps sending its notifications to the production URL, and that is fine. What must not happen is the copy registering a new webhook pointing to itself in the live account.
• Bank transfer and cash on delivery: they do not charge anything, but they generate emails to the customer with instructions. They are already covered if email is captured.

Step 4: make sure nobody finds it

A copy reachable from the Internet ends up indexed if you do not prevent it, and then it competes with your own store in Google with the same content.

• Password protection on the web server (basic authentication). This is the most effective: neither search engines nor curious visitors get past the first screen.
• noindex header on every response, as a second layer.
• PrestaShop's maintenance mode with your IP allowed, if you cannot set a password.

Do not rely on robots.txt alone: it asks search engines not to crawl, but it does not stop a URL linked from somewhere from appearing in the results.

Step 5: connections to the outside world

This is where most surprises lie, because every store has its own:

• Scheduled tasks. If you also copy the crontab, the copy will run the same tasks: exports to the ERP, synchronisation with marketplaces, newsletter sends. Disable them and re-enable them one by one only if you are going to test them.
• ERP and warehouse. A connector that creates orders or updates stock in the real ERP is dangerous from a copy: it can duplicate orders or overwrite stock with test data.
• Marketplaces and feeds. A module that publishes products or syncs stock with a marketplace will use the real credentials.
• Tracking pixels and analytics. Visits to the copy pollute the real store's statistics and can send fake conversions to advertising platforms.
• Carriers. Some modules generate labels or request collections through the carrier's API.

Step 6: the domain

PrestaShop stores the store's domain in the database (in the shop URL table and in the configuration). If you do not change it, the copy redirects to the real store as soon as you open it. After changing it, clear the cache and regenerate the friendly URL file. Also search for the old domain in module settings and CMS content: an absolute link to production inside the copy can make you think you are testing one thing when you are looking at another.

Checks before you start working

1. Place a test order and check that the email appears captured and does not go out.
2. Search the database for any real customer email: there should be none left.
3. Open the copy without a session from another browser: it should ask for a password or show maintenance mode.
4. Review which scheduled tasks are active and which modules have credentials for external services.

A copy like this is a tool you can use without fear for every update, every new module and every theme change, and it is the basis for keeping the store up to date without your customers being the ones who test.

How to solve it in PrestaShop

At Rekire we always work on copies of this kind: email captured, data anonymised, gateways in test mode and external connections cut off. With a support hours package we set up a copy of your store and leave it ready for rehearsing updates and changes, or we make those changes on it ourselves before taking them to production. And if you are looking for hosting designed for PrestaShop, Rekire's Hosting plan profesional is our offer for stores that want to stop worrying about the server.