WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

#16964 closed enhancement (wontfix)

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

Reported by: philipwalton Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Multisite Keywords: needs-testing has-patch
Focuses: Cc:

Description

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 );	
		}
	}
}

Attachments (1)

ms-functions.diff (1.2 KB) - added by philipwalton 4 years ago.

Download all attachments as: .zip

Change History (7)

@philipwalton4 years ago

comment:1 @nacin4 years ago

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.

comment:2 follow-up: @philipwalton4 years ago

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.

comment:3 in reply to: ↑ 2 ; follow-up: @nacin4 years ago

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.

comment:4 @scribu4 years ago

Similar discussion: #14170

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

comment:5 in reply to: ↑ 3 @philipwalton4 years ago

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")

comment:6 @scribu4 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

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

Version 0, edited 4 years ago by scribu (next)
Note: See TracTickets for help on using tickets.