Uninstall button and routine

[boonebgorges]

BP's deactivation hook bp_loader_deactivate() (bp-loader.php) deletes a bunch of live site options. This is a Bad Idea, especially because plugins often have to be deactivated for testing and maintenance (and upgrades!).

Three options:
1) Remove the deactivation hook altogether
2) Leave it, but modify it from removing site options that are still valid
3) Leave it, but just for the do_action() hook.

My vote is for option (3). There might still be reasons why some other plugin would want to hook to BP activation, so it's worth it to keep the hook. The removal of stale settings should be done by proper upgrade routines like the one in bp-core-upgrade.php (in case someone wants to deactivate/activate without updating).

[nacin]

4) uninstall.php plz :-)

[jeffsayre]

Since we've basically been debating the idea behind this ticket on Twitter, I thought it best to bring the discussion to were it belongs--this ticket.

Here's a recap of some of my comments and thoughts on this issue:

1. Plugin deactivation is different than plugin uninstalling. They are different events in WP's plugin API.

2. There is value in deactivation routines. They can be used to allow Site Admin to reset the plugin's environment back to initial defaults without having to uninstall and then reinstall a plugin. But the resetting (deleting of) plugin meta data (the stored serialized options data) shouldn't be done automatically on deactivation. Site Admins should have control over if and when a plugin's meta data are reset.

3. Whereas I have a function that hooks to register_deactivation_hook(), just as most (all?) BP plugins do, I disable all of the delete_site_option() and delete_option() calls and instruct admins to uncomment these lines if they need to reset the plugin's environment to default settings. This is bad and not user friendly.

4. So, I've considered a more useful approach: create an Admin setting that allows the Site Admin to indicate whether meta data should be purged upon plugin deactivation. The function hooked to the deactivation event will use a constant to determine whether or not any delete_site_option() and delete_option() calls should be fired.

5. Andrew Nacin suggested another approach which I believe is better. WordPress should have a "Defaults" button in the plugins menu that allows a Site Admin to easily restore a plugin back to its original factory settings with a simple push (and I assume with various warning messages and a confirmation button). This button is a nice idea, offers very clear meaning, and would obviate the need for a special function hooked to register_deactivation_hook(). Instead, there would need to be a function hooked to a new Plugin Defaults hook.

6. The Plugin Defaults hook is something that would have to be added to WP's core, to the Plugin API (see: /wp-includes/plugin.php).

So, if we go this route, this becomes a WP ticket and not a BP ticket.

[sbressler]

FYI: If you want the "Defaults" button on the plugin page along with "Deactivate | Edit", while it could be added to core, you could do it yourself, too, without anything being added to core. Just use something like this:

function bp_action_links( $links, $file ) {
	$plugin_file = basename( __FILE__ );
	if ( basename( $file ) == $plugin_file ) {
		$settings_link = '<a href="[link or JavaScript to reset BP to default settings">Reset to Default</a>';
		array_unshift( $links, $settings_link );
	}
	return $links;
}
add_filter( 'plugin_action_links', 'bp_action_links', 10, 2 );

Though forgive me if I'm misunderstanding the approach you suggest in 5.

[boonebgorges]

I am going to remove all of the delete_site_options() calls from the deactivation hook (but leave it in place for the 'bp_loader_deactivate' action). That will solve the immediate problem at hand. Then I'm going to flip this ticket into an enhancement request for a proper uninstall procedure.

[boonebgorges]

(In [3549]) Don't delete site options when BP is deactivated. See #2755

[DJPaul]

This would be great to get into 1.6 if someone can provide a patch. Otherwise, it'll get punted.

[ddean]

uninstall.php proposal

[ddean]

Replying to nacin:

4) uninstall.php plz :-)

This seems like the easiest way to do an uninstall routine.

[boonebgorges]

Patch looks sensible to me. I feel very uneasy about auto-deleting data upon deletion (ddean's patch does not do this). If we're going to have a BP table-deletion routine, we really must have a UI for it, which gives multiple levels of warning about the irretrievability of data. In the meantime, the proposed patch seems like a reasonable addition. Thoughts from others?

[DJPaul]

The proposed patch *does* have a placeholder function to drop tables. I think if we just dropped the settings, and the user re-activated the plugin, I think the wizard might get stuck. uninstall.php is only triggered when the "Delete" plugin option is hit.

[boonebgorges]

I think if we just dropped the settings, and the user re-activated the plugin, I think the wizard might get stuck.

That would need testing, which we don't have time for this cycle :) We should do this very early in the next cycle, though, as not having anything in place makes us Bad Citizens.

[boonebgorges]

Let's look at this for 1.7.

[johnjamesjacoby]

Patch is a good start, but no time for this in 1.7. Moving to 1.8.

[slaFFik]

I see the value in uninstall.php and BuddyPress cleanup, so I would like to bring this for 2.8 release.

[slaFFik]

We definitely need to do this, but this is a too big task for the remaining time in 2.8 release cycle.

[DJPaul]

We're closing this ticket because it has not received any contribution or comments for at least two years. We have decided that it is better to close tickets that are good ideas, which have not gotten (or are unlikely to get) contributions, rather than keep things open indefinitely. This will help us share a more realistic roadmap for BuddyPress with you.

Everyone very much appreciates the time and effort that you spent sharing your idea with us. On behalf of the entire BuddyPress team, thank you.

If you feel strongly that this enhancement should still be added to BuddyPress, and you are able to contribute effort towards it, we encourage you to re-open the ticket, or start a discussion about it in our Slack channel. Please consider that time has proven that good ideas without contributions do not get built.

For more information, see ​https://bpdevel.wordpress.com/2018/01/21/our-awaiting-contributions-milestone-contains/
or find us on Slack, in the #buddypress channel: ​https://make.wordpress.org/chat/