admin管理员组

文章数量:1122846

A plugin author I am speaking with has created their plugin so that its database tables remain intact upon plugin deletion... Their statement is that people might want to install it again and retain their data/settings.

Personally I think this is pretty bad practice, and a poor assumption at that. I think uninstalling should coincide with an expectation of data retention; uninstallation with deletion.

However it makes me curious:

From a UX perspective, is it possible to warn users before deleting that associated DB tables will be deleted?

If so, generally how could a plugin do this? Is there something we can hook into the delete process with and interrupt it with an "are you sure?" message?

A plugin author I am speaking with has created their plugin so that its database tables remain intact upon plugin deletion... Their statement is that people might want to install it again and retain their data/settings.

Personally I think this is pretty bad practice, and a poor assumption at that. I think uninstalling should coincide with an expectation of data retention; uninstallation with deletion.

However it makes me curious:

From a UX perspective, is it possible to warn users before deleting that associated DB tables will be deleted?

If so, generally how could a plugin do this? Is there something we can hook into the delete process with and interrupt it with an "are you sure?" message?

Share Improve this question edited Apr 8, 2024 at 18:36 Drewdavid asked Apr 7, 2024 at 20:48 DrewdavidDrewdavid 2191 silver badge12 bronze badges 6
  • note that a plugin can be removed without its uninstallation routine running, this is the norm for a lot of hosts that use git based deployment mechanisms, tools like composer, as well as those who delete the plugin folder. Any "prompt" or "warning" that blocks the uninstallation flow might actually break lots of automation or tooling, e.g. how would a prompt work for a command line tool uninstalling the plugin? Or if the plugin is uninstalled from a web hosts control panel UI. I'm not suggesting what you are asking isn't possible, but that it might not be a great idea implemented as is – Tom J Nowell Commented Apr 8, 2024 at 8:48
  • Thanks @TomJNowell. Great point, never thought of that! I wonder if a JavaScript-based solution could work, such that if JS is enabled it does the check / user prompt, otherwise it just goes ahead with the deletion? Does that seem like a plausible option? – Drewdavid Commented Apr 8, 2024 at 20:49
  • And also, do you know, is it even technically possible to do what I am asking about: issue a warning (in the UI, though perhaps there is a way to issue a warning programmatically as well?) that must be consented to before the uninstallation proceeds? Thanks again. – Drewdavid Commented Apr 8, 2024 at 22:54
  • 1 I believe it's "sort of" possible but not in the nice neat way you're hoping it to be, it's much more likely to cause accidental deletion and break things than to actually warn the user. As I mentioned it's an awful UX idea if only because the failure case is the unintended destruction of customer data, and WordPress provides no mechanism for doing it, any answer would be an awful hack/kludge with potential security consequences, the kind of code that would get you fired from most big WP agencies. It would be irresponsible of the plugin author to integrate such a solution – Tom J Nowell Commented Apr 9, 2024 at 8:17
  • 1 cleanup documentation would be best, since that covers all the cases where the plugin was uninstalled manually or by automation, which wouldn't trigger uninstall.php, likewise if there was a problem and the uninstall routine couldn't run they could use docs to perform cleanup. It's also very useful for help with backing up that data specifically, and debugging problems. – Tom J Nowell Commented Apr 11, 2024 at 7:52
 |  Show 1 more comment

2 Answers 2

Reset to default 1

When a user decides to uninstall a plugin in WordPress, it's up to the plugin author to define what actions should be taken during the uninstallation process. This can be achieved by setting up a callback function for the uninstall hook (or providing an 'uninstall.php' file within the plugin's directory):

register_uninstall_hook( __FILE__, 'my_plugin_uninstall_callback' );

function my_plugin_uninstall_callback() {
    // Code to remove associated database tables or perform cleanup tasks
}

Contrary to the common assumption, it's the responsibility of the plugin author to ensure a smooth uninstallation experience. This typically involves writing code to clean up any created database tables or data stored in standard tables.

Moreover, plugin authors can enhance user control and experience by integrating settings within the plugin's options. By providing users with the ability to specify the fate of their data post-uninstallation directly from the plugin's settings, authors can empower users and ensure a seamless experience. Additionally, actions such as:

do_action( 'pre_uninstall_plugin', $plugin, $uninstallable_plugins );

can be leveraged within the plugin's code to accommodate user preferences and further enhance flexibility and usability.

There is no reliable way to do this, and for one simple reason, you need to run code to do it, so if your plugin is deactivated there's no way to intercept it in WP Admin to show the prompt.

The only way to achieve the goal reliably involves massive security problems and the breaking of a huge amount of automation and APIs.

First you would take realloc's answer and implement an uninstall.php. Inside the uninstallation hook you would then add a check for a confirmation flag. If none is found print a confirmation form that submits to itself but with the confirmation flag. If the flag is found delete the tables.

Consequences:

  • the plugin can only be uninstalled via the WP Admin plugin screen, all other methods of plugin management are now broken.
    • WP CLI, REST API, composer, even remote management tools such as the WordPress mobile app, Jetpack, WP Remote, etc etc
  • malicious users could manually visit your uninstall.php directly
  • you've broken the users UX expectations by interfering with the standard flow
  • this is going to look suspicious to anti-virus tech

While I understand the good intention behind it, this is not the solution, and would be poor UX. Fundamentally this is an X Y problem, where the original problem is that the expectations of uninstalling a plugin did not meet reality, and no standard is set that can be conformed to.

本文标签: Possible to issue a warning before plugin deletion (iethat tables will be deleted)