detect a staging environment like WooCommerce Subscriptions does
It would be great if Automate Woo would deactivate email sends if it detects that the site is a staging site, similar to how WooSubscriptions works. Thank you 🙂
Lauren Goldstein: I think we will probably end up integrating with the either the new wp_get_environment_type() function or with "WooCommerce test mode" that might be coming to core next year. Preferably the latter option. However, I can suggest a couple of solutions that I’ve used personally on development sites.
Get your developers to always have the following definition in their wp-config.php file on dev sites: define( 'AW_PREVENT_WORKFLOWS', true );
This prevents all workflows from running.
Dan Bitzer: Do you have any updates on this. This happened to us AGAIN where one of the devs accidentally re-activated the plugin before it was fully ready for live off the dev site and it sent HUNDREDS of emails with the dev email. This really is a huge pain point for us that there is no way to detect dev sites or globally pause or clear cache so it doesn’t send from Dev sites.
Lauren Goldstein:
> Do you have any advice for how we can cleanly get the live version back on the new live site?
This is definitely a challenging problem and it’s not something I’ve had to do for years (thankfully). I’d definitely exclude certain tables and post types when importing the database on the live site. You can use WP Migrate DB pro for that.
You need to avoid replacing the user table, orders, workflows, subscriptions or any AutomateWoo tables as a start. I’d contact Woo support, they may have some tips.
Dan Bitzer: You and me both. I think I have a few more grey hairs now ha! Do you have any advice for how we can cleanly get the live version back on the new live site? What I mean is we are building out the new version on the dev side and then want to copy that over to the live side when it is done but I am concerned that we will muck out automate woos queues and such that are on the current live site because there isn’t an export function for it. Could we do something with the database you think?
Dan Bitzer I 1000% percent agree as we had an incident where our new dev didn’t realize it didn’t detect staging and copied our live site and it sent emails to our customers from the dev site. It was a disaster. Is this on the roadmap?
I second this. Plugins like Woocommerce Subscriptions already has this functionality builtin by storing the original site_url in the db. Having this feature available and working also in AutomateWoo would allow for easier development as using a staging site plugin such as duplicator or wp-staging would then be a breeze
Lauren Goldstein: I think we will probably end up integrating with the either the new
wp_get_environment_type()function or with "WooCommerce test mode" that might be coming to core next year. Preferably the latter option.However, I can suggest a couple of solutions that I’ve used personally on development sites.
wp-config.phpfile on dev sites:define( 'AW_PREVENT_WORKFLOWS', true );This prevents all workflows from running.
Dan Bitzer: Do you have any updates on this. This happened to us AGAIN where one of the devs accidentally re-activated the plugin before it was fully ready for live off the dev site and it sent HUNDREDS of emails with the dev email. This really is a huge pain point for us that there is no way to detect dev sites or globally pause or clear cache so it doesn’t send from Dev sites.
Dan Bitzer: Thank you. I look forward to it. It is something that can be easily forgotten to turn off Automate Woo in staging. Thank you. 🙂
Dan Bitzer: Agreed! Definitely not the most ideal situation so fingers crossed. Thank you for your help! Keep me posted 🙂
Lauren Goldstein:
> Do you have any advice for how we can cleanly get the live version back on the new live site?
This is definitely a challenging problem and it’s not something I’ve had to do for years (thankfully). I’d definitely exclude certain tables and post types when importing the database on the live site. You can use WP Migrate DB pro for that.
You need to avoid replacing the user table, orders, workflows, subscriptions or any AutomateWoo tables as a start. I’d contact Woo support, they may have some tips.
Dan Bitzer: You and me both. I think I have a few more grey hairs now ha! Do you have any advice for how we can cleanly get the live version back on the new live site? What I mean is we are building out the new version on the dev side and then want to copy that over to the live side when it is done but I am concerned that we will muck out automate woos queues and such that are on the current live site because there isn’t an export function for it. Could we do something with the database you think?
Lauren Goldstein: Sorry to hear that Lauren! It’s not planned for our next release but I’ll try and have this included in the following one.
Dan Bitzer I 1000% percent agree as we had an incident where our new dev didn’t realize it didn’t detect staging and copied our live site and it sent emails to our customers from the dev site. It was a disaster. Is this on the roadmap?
I second this. Plugins like Woocommerce Subscriptions already has this functionality builtin by storing the original site_url in the db. Having this feature available and working also in AutomateWoo would allow for easier development as using a staging site plugin such as duplicator or wp-staging would then be a breeze