A testing environment (staging) for your webshop
A staging environment (staging) is a copy of your website where you try out updates and changes, without visitors being affected by it. With a webshop that's extra useful, but also extra risky: a copy of your shop contains real customer data and can carry out real actions. It can send mail to customers, receive payments, or put invoices in your bookkeeping. Here you can read what to arrange for a shop right after copying, and why you should never restore the staging database over your real shop.
Making a copy
With WebOké you create a staging environment using Copy (clone) in Installatron, with the Create a staging site? option. Put the copy on a subdomain, for example test.example.com. The steps are in Creating a WordPress staging environment and in more detail in Cloning and creating a staging environment. In My WebOké you can also do this with Clone website in the Website Manager.
Shield the copy with a password on the folder (see Password-protected folders) and in WordPress under Settings > Reading, tick the box to discourage search engines.
Right after copying, before anything else
- Payment provider in test mode. Set the payment plugin on the copy to test mode, with test keys. With live keys, a staging site can receive real payments or process real refunds.
- Turn off or redirect mail. Otherwise a copy sends confirmations, reminders, and abandoned cart emails to real customers. Use a plugin that blocks all mail or sends it to a single test address.
- Turn off integrations and webhooks. Bookkeeping, inventory sync, shipping labels, email marketing: otherwise staging will book invoices or create shipping labels. Also check WooCommerce > Settings > Advanced under Webhooks and the API keys.
- Review scheduled actions. The queue has been copied too. Pending actions, such as a reminder email or a subscription payment, will otherwise run again on staging. See WooCommerce Status and Scheduled Actions: troubleshooting.
- Limit personal data. If you don't need real customer data to test, remove or anonymize it on the copy. A staging site is also subject to privacy rules, and is often less well secured.
If you sell downloads, those files are also on the copy. That's another reason a password belongs on it.
Never restore the staging database over your real shop
Between copying and restoring, your real shop gains new orders, customers, payments, and stock changes. If you restore the staging database over your real shop, you lose all of those. This also applies to Synch (Synchronize) in Installatron: this overwrites files and database content of your real site.
So work like this:
- Test on staging, then carry it out on your real shop. You now know the change works; repeat the same steps on production.
- Only transfer files, such as an adjusted theme, if that's sufficient.
- Does it still need to involve the database? Only do it with the shop in maintenance mode, right after a fresh backup, and with a tool that skips orders and customers.
Testing an update: a fixed route
- Make a fresh copy of your real shop and properly set up the five points above.
- Update WooCommerce, your payment plugin, or your theme on the copy, and run the database update if WooCommerce asks for it.
- Place a test order in test mode: a payment, a failed payment, and a refund.
- Check WooCommerce > Status for scheduled actions and logs.
- Then update your real shop at a quiet moment, with a backup right before.
- Remove the copy when you're done, or keep it shielded for next time.
Further reading
- Free WordPress course, lesson 8.3 Staging: testing safely
- Making and restoring backups in Installatron
