WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 6 years ago

#8783 closed enhancement (invalid)

Plugin Uninstall - Make it optional to uninstall the plugin on delete if uninstall.php exists within the plugin folder

Reported by: sc0ttkclark Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Plugins Keywords: dev-feedback
Focuses: Cc:

Description

There could be a function similar to

register_activation_hook( __FILE__, 'myplugin_activate' );

which could look like this

register_delete_hook( __FILE__, 'myplugin_delete' );

So that when you delete a plugin from the Plugin Admin interface, it will check the plugin's main file for that hook, if found it will run that function. The purpose of this would be to allow the plugin to cleanup data.

An optional prompt should be used on the delete screens to ask the user if they want to clear the plugin's "data" (only if the delete hook is found for the plugin). That would be most optimal.

Right now the only option is to go through that plugin, us the 'reset' function or something similar, deactivate, and then delete the plugin. It seems more logical to have a built-in wordpress hook that could call the plugin's delete function to remove the data.

Change History (16)

comment:1 @sc0ttkclark6 years ago

  • Type changed from enhancement to feature request

comment:2 @mrmist6 years ago

I thought that this was available by putting an uninstall.php in your plugin directory? Was that not implemented? Maybe I imagined it.

comment:3 @sc0ttkclark6 years ago

  • Type changed from feature request to enhancement

Actually you are correct, so a new hook wouldn't be needed, but the uninstall should be optional to the user instead of included by default.

http://codex.wordpress.org/Migrating_Plugins_and_Themes_to_2.7#Uninstall_Plugin_API

comment:4 @sc0ttkclark6 years ago

  • Summary changed from Plugin Delete - Allow hook similiar to register_activation_hook for when a Plugin is Deleted via Plugin Admin to Plugin Uninstall - Make it optional to uninstall the plugin on delete if uninstall.php exists within the plugin folder

comment:5 @jacobsantos6 years ago

I think you misunderstand the intentions of what the uninstall on delete is primarily for.

comment:6 @jacobsantos6 years ago

What I mean is that your use case is fringe at best.

comment:7 @jacobsantos6 years ago

However, your primary points are not invalid.

comment:8 @sc0ttkclark6 years ago

Maybe there's a way to set the Description for this ticket to this to be more exact on what it's requesting:

When deleting a deactivated plugin through WordPress, the user should be presented with an option to run the plugin's "uninstall" process. If accepted, the "uninstall" process will run. Otherwise, the delete process will skip the "uninstall" process. If no "uninstall.php" file is found or the register_uninstall_hook is not set, then the prompt will not be shown.

This is to allow the ability for the user to retain plugin information for backup purposes.

comment:9 @Denis-de-Bernardy6 years ago

  • Keywords dev-feedback added; plugins delete clean removed

simpler: the plugin should run the deactivate_plugin hook before being deleted no?

comment:10 @sc0ttkclark6 years ago

I'm just calling for a confirmation step before uninstall.php or the uninstall hook's function is ran.

comment:11 @DD326 years ago

simpler: the plugin should run the deactivate_plugin hook before being deleted no?

No. The plugin is not active, And therefor, The deactivation hook should not be run.

The plugin has to be first inactive in order for the user to be able to delete/uninstall it, So the deactivation hook has already been run at some point in the past.

comment:12 @jacobsantos6 years ago

The discussions with Ryan Boren (core developer, works for Automattic), I believe I discussed having the uninstall optional. Basically, the setup would be that you had a button to uninstall the plugin with the delete button.

The problem with this is that it was slightly confusing with its use case. It was decided and agreed that someone who is deleting a plugin most likely will want nothing to do with it again and therefore the plugin should clean up after itself. If the user decides it wants the information, they can either look at a backup of their database or reconfigure the plugin again at a later date.

I agree, that at least some users will want to at some point reinstall the plugin and be confused when they've lost all of their settings. However, if they wanted to at some point reactivate the plugin, they would have just kept it inactive until which point they wanted it again and reactivate it with their settings.

comment:13 @jacobsantos6 years ago

Quite simple really, if you want people to keep their settings, have a setting in your plugin that lets you know they want to keep their settings.

comment:14 @sc0ttkclark6 years ago

What if there was a checkbox labeled "Keep Plugin Data" on the Delete confirmation screen so that the user can decide if they want to keep the data. I understand that the terminology between Uninstall and Delete are confusing, and in most cases people would like to do both, so this would solve that issue and allow for users to keep that data.

However, I do understand that this discussion has already been brought up as per jacobsantos has explained, but I was hoping that the option explained in my above paragraph could be reviewed for inclusion. It can't "hurt", and it would default to "off" so that nothing changes in the delete routine unless the user decides to "opt-in".

That said, I won't push any further if the above option is reviewed and an executive decision is made that it is not for the good of WordPress users.

comment:15 @jacobsantos6 years ago

I'll rather the user be able to choose whether or not the data was uninstalled.

comment:16 @Denis-de-Bernardy6 years ago

  • Milestone 2.8 deleted
  • Resolution set to invalid
  • Status changed from new to closed

such a hook is irrelevant, because it cannot be run if you delete the plugin using FTP.

Note: See TracTickets for help on using tickets.