Staging is like a twin brother to production – they should look and behave the same, with an exception or two. Let’s resolve the obvious scene. Staging technology stack should be as close as possible to your production environment. This specifically includes having the same Linux, PHP, MySQL version, all of the PHP libraries and network settings. In that manner, your newly deployed production commit will behave like you tested it in staging.
Today’s topic is not about these similarities. Instead, we’ll be talking about small flavours that differentiate staging from production as this is something that always comes up in the meetings with clients and their IT team. We will focus on eCommerce staging environments, specifically LAMP stack, that host WooCommerce or any other LAMP based OpenSource platform like Magento, osCommerce or OpenCart.
Here are the three main things that separate functions on staging server from production:
- Staging environment should obfuscate personal and private data to agreed extent. Client’s legal or business needs define these settings and to be honest, this is not a simple topic – just one look at StackExchange thread will open up dozens of additional questions.
- Credit Card processing should be connected to testing platform of integrated payment gateway. Setting up testing payment gateway is supported by most of the providers like Stripe, Braintree, PayPal, WS Pay and should be a point and click setting for most use cases.
- Staging environment should not send transactional emails or notifications to customers during manual or automated testing. Emails that fall under this category are: new order emails, cancel order, refund order, forgot password or new account emails. List of all possible emails can be found and tested by our Woo email previewer.
Regarding that last bullet, the system should be able to mimic all eCommerce functions. In the end, developers need a way to troubleshoot if triggers for these email blasts are not functioning. Neuralab staging email rerouter is a plugin used to reroute all of these outgoing emails sent by WordPress staging environment (order mails, registration, etc.). It catches emails and reroutes them to a specified email address you want – preferably developers email. The idea behind is not to spam your clients with transactional emails when testing out if Woo functions correctly. Instead, you receive and analyze when they were sent and what is the exact content.
Installation is pretty simple:
- Go to our Github repo – https://github.com/Neuralab/Neuralab-Staging-email-rerouter
- Download the files and copy them to the /wp-content/plugins/ directory
- Activate the plugin through the ‘Plugins’ menu in WordPress
- Navigate to NRLB Reroute in admin menu
- Check the “Check this box if you want to enable email rerouting” checkbox to enable the plugin
- In the “Email Address” input field, enter an email address to where you want to redirect WordPress emails (this will be mainly your development email or even Zapier email hook for further automation – https://zapier.com/zapbook/email/)
This plugin is written with our clean&simple methodology in mind i.e. it does only one thing and nothing more. You can download it on our Github repo, together with some other interesting Woo utilities.