New function network_delete_option($option) to help keep option clutter to a minimum

[philipwalton]

When I create uninstall.php files for plugins I always delete the options I created using delete_option(). However, recently I realized that if anyone is using my plugins on a multisite installation, delete_option() would only delete that option from the options table of the main site; not any of the subsites.

I believe a function should be created to make removing options as easy as possible, so I created a function called network_delete_option().

The patch I've included is to the ms-functions.php file. Perhaps it is more appropriate somewhere else, but I just want to get the discussion started.

Here is the code:

/** 
 * Deletes the option from all options tables
 *
 * @uses delete_option()
 *
 * @param mixed $options a string or array of strings which correspond to the option names to be deleted
 */
function network_delete_option( $options ) {
	
	// convert an option passed as a single string to an array
	if ( is_string( $options ) ) {
		$options = array( $options );
	}
	
	if ( is_multisite() ) {
		global $wpdb;
		$blogs = $wpdb->get_results( "SELECT blog_id FROM {$wpdb->blogs}", ARRAY_A );
		if ( $blogs ) {
			
			// loop through each subsite ( blog )
			foreach( $blogs as $blog ) {
				switch_to_blog( $blog['blog_id'] );
				
				foreach( $options as $option ) {
					delete_option( $option );	
				}
			}
		}
	} else {
		
		// loop through each subsite ( blog )
		foreach( $options as $option ) {
			delete_option( $option );	
		}
	}
}

[nacin]

This doesn't scale.

Uninstall hooks (and activation hooks) suck on networks. For an activation hook you'd want to leverage an upgrade function instead. For uninstall hooks, the super admin will be the one triggering this, so the onus is on them to ensure fat options are cleaned up. Nothing else we can really do.

[philipwalton]

Nacin, thanks for the feedback.

I don't know if this matters, but where I'm currently using this function is not in a deactivation hook, but rather in the uninstall.php file. I've tested it on my multisite blog, and it does seem to work well. Are you recommending not running the code I've posted?

As far as putting the onus on super admins to clean up options, while it would be nice, it doesn't seem reliable. How are they to know specifically what options each plugin they activate is saving to the database?

It seems to me that the onus should be on the plugin developers.

[nacin]

Replying to philipwalton:

Nacin, thanks for the feedback.

I don't know if this matters, but where I'm currently using this function is not in a deactivation hook, but rather in the uninstall.php file. I've tested it on my multisite blog, and it does seem to work well. Are you recommending not running the code I've posted?

Yes, on any site with a real number of blogs. Whether that's 18.6 million or even a few hundred.

As far as putting the onus on super admins to clean up options, while it would be nice, it doesn't seem reliable. How are they to know specifically what options each plugin they activate is saving to the database?

This function isn't doing that either, mind you.

It seems to me that the onus should be on the plugin developers.

It really can't be though. Not at the scale that multisite can operate on.

[scribu]

Similar discussion: #14170

I should probably update my ​Proper Network Activation plugin to handle uninstalls too.

[philipwalton]

Nacin, I guess that's true about sites with a very large number of blogs. Excellent point.

When you say "This function isn't doing that either, mind you", what are you saying it's not doing? I'm not following you.

Finally, do you advise -- as a general rule -- to not spend much time worrying about plugin cleanup on a multisite setup? If that is a general operating principle, it would certainly give me a lot less to worry about. (At least until network activation/uninstall hooks don't "suck")

[scribu]

It seems to me that the onus should be on the plugin developers.

It really can't be though. Not at the scale that multisite can operate on.

The onus shouldn't be on plugin developers, or on super admins.

It should be on WP Core, just like it is when a database upgrade is required.

Yes, it might take two weeks to finish, but at least the super admin doesn't have to go running around for custom scripts to get the job done.

Anyway, as nacin said, the approach provided in this ticket doesn't scale. Closing as wontfix.

PS: Nacin can reply even with the ticket closed.