Stop Emails First?

[jessLundie]

Scenario

Local development site, accidental unscrubbed version of the DB.

• Loaded up, realized DB was intact
• Installed Safety Net
• Received this email to our concierge@ email address:

Maybe this is fine - trying to think this through... Should we be stopping emails before we scrub data?

[NickGreen]

@jessLundie wp_mail should be blocked as soon as the plugin itself is loaded: https://github.com/a8cteam51/safety-net/blob/trunk/includes/admin.php#L31

Is it possible that you didn't have the WP Env constant set to something other than production before loading the site up?

Edit: hmm, never mind. The scrubbing wouldn't have happened if the constant wasn't set.

[NickGreen]

@nate-allen While thinking this one through, I wonder if you could look at something with me.

~It looks like the plugin is 1. deactivating plugins and then 2. scrubbing the options: https://github.com/a8cteam51/safety-net/blob/516e7f5888da2039395cfc3d75a5303ee40f03af/includes/deactivate-plugins.php#L7-L8~

~Is this right? I thought, and according to the README, that we should 1. scrub options and then 2. deactivate plugins. I thought there was a 3rd party plugin (Klaviyo?) that we needed to disconnect from the API before deactivating on development sites.~

Nevermind, those actions are just confusingly added. The functions that actually run them are here: https://github.com/a8cteam51/safety-net/blob/516e7f5888da2039395cfc3d75a5303ee40f03af/includes/bootstrap.php#L12-L13

[GeoJunkie]

Noting that we've had another issue with this: p9MPsk-6lt-p2#comment-37290

[nate-allen]

Maybe we shouldn't be using update_option at all, and using $wpdb->query directly, like we do when deleting users.

$wpdb->query("UPDATE {$wpdb->options} SET option_value = 'safetynet@scrubbedthis.option' WHERE option_name = 'admin_email'");

Since update_option has hooks, a plugin could do something unexpected when an option is updated (like it did with the admin email)

[GeoJunkie]

@nate-allen I implemented your idea in a more general sense to account for any other unexpected behaviors. #127 should fix this. Can you give it a quick look when you have a moment?