Stop Emails First?

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?

@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.

@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:~~

safety-net/includes/deactivate-plugins.php

Lines 7 to 8 in 516e7f5

    
           add_action( 'safety_net_deactivate_plugins', __NAMESPACE__ . '\deactivate_plugins' ); 
        
           add_action( 'safety_net_scrub_options', __NAMESPACE__ . '\scrub_options' );

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:

safety-net/includes/bootstrap.php

Lines 12 to 13 in 516e7f5

    
           add_action( 'safety_net_loaded', __NAMESPACE__ . '\maybe_scrub_options' ); 
        
           add_action( 'safety_net_loaded', __NAMESPACE__ . '\maybe_deactivate_plugins' );

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

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)

@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?

	add_action( 'safety_net_deactivate_plugins', __NAMESPACE__ . '\deactivate_plugins' );
	add_action( 'safety_net_scrub_options', __NAMESPACE__ . '\scrub_options' );

	add_action( 'safety_net_loaded', __NAMESPACE__ . '\maybe_scrub_options' );
	add_action( 'safety_net_loaded', __NAMESPACE__ . '\maybe_deactivate_plugins' );