Plugins that do not clean up after themselves

Why is that a problem? If the option to delete data is there in the plugin’s settings, and the user later decides s/he wishes to delete all that data, the remedy is simple. S/he reinstalls the plugin, changes the option to delete data, and deletes the plugin again. Voilà!

This scenario assumes that the user did not select “I want this plugin to delete its data upon uninstall” at some earlier point and then accidentally deleted the wrong plugin or a dozen other things that could go wrong.

Now I’m just confused about what you’re trying to achieve. The title of the thread relates to plugins that do not clean up after themselves. What exactly are you concerned about?

1 Like

I would like the plugin to clean up AFTER the user confirmed that this is what they actually want to do.
Having to choose between cleaning up after itself and requiring confirmation is a false dichotomy.

This is from the ClassicPress installation I created today:

image

Do you propose that this should be removed from core?
Trying to understand.

Then I think you are misguided. As I said before, users are often panicky when they delete a plugin. That isn’t the time to expect them to make such an important decision. They should either already have made that decision in calmer circumstances, or else have the chance to come back and change their minds later (which is what reinstalling, changing a setting, and then re-deleting enables).

Doing it your way would lead to much data being deleted that the user did not really want deleted. That’s much worse than the inconvenience you are trying to address.

1 Like

I respectfully disagree with that.

I think the decision SHOULD be made before hand.

I ALSO think that the decision should be confirmed before the action is taken (if only to confirm that the action was actually intended, instead of a finger error).

It isn’t one or the other.

I think it’s terrible UX for accessibility reasons. Just try tabbing into that pop-up!

I also think it’s misleading because it doesn’t delete stuff stored in the database. But I’m not currently proposing a change. At the moment, I am simply responding to your suggestion of whether and how a change should be made. In my view, adding an even more important decision to be made at that stage (and certainly by that method) would make things much worse.

It seems the discussion about confirmation notices may need it’s own forum thread since there are obviously pros and cons on both sides as well as tough decisions to be made about what is the best method for confirmations to be presented.

I don’t know how much enforcement over a given method we should consider though because plugins will be implementing these confirms themselves in there own plugins.

That notice is generated by core, not by the individual plugin.
I agree that the form confirmations ought to take is a separate discussion.
What data a plugin should delete (by default and which choices ought to be offered) and the nuances of when which option is better, is independent from whether confirmation is asked for or not.

Accessibility is a fair consideration.

In this case, the terrible UX must be contrasted with terrible internal control and with terrible business practice.
Asking me to accept the ToS, or confirm my age, for example, is inherently a confirmation that the action is an intended action.
Confirmation is an integral part of internal control.
I am all for improving accessibility, but it can’t be done at the cost of good business practice.
And it doesn’t need to.

A fair point. Which is why I suggest that upon deleting a plugin, you ought to confirm your previously made choice.
Currently, however, only a handful of plugins out there offer you that choice at all, at any point in the process.

The average user never even sees which tables / options / meta data is stored in their DB.
And if they went through their options table, they would not know which options are standard and which were added by plugins, or which plugin added which option.
They just assume once they deleted the plugin, the related bloat is gone.
And it often isn’t.
There ought to be a solution for that.

@anon71742606 if that notice is generated by core why is it asking to confirm deletion of the data? I thought this thread was about how that data should be cleared up. If core already handles deletion and provides a confirmation what else needs changed to make it work like you imagined?

I am saying that a user who selects “Are you sure that you want to delete this plugin and its data?” is under the assumption that the plugin’s data is being deleted.

Yet I have just seen plugins that registered ten or more options and did not delete them once the plugin was deleted.
I have seen plugins that created six custom tables, but did not delete them once the plugin was deleted.
(And note that I did not actually create any user-generated content with this plugin. It literally creates the tables and leaves them there if I install and delete it immediately afterwards.)
I have seen plugins that created 20k to 50k lines per custom table.
Again, without me actually having used these plugins to create any content (so this does not relate to user-generated custom post types, for example.)

Removing unused plugins is a security recommendation.
Yet a lot of tables, data and options are not being deleted when the plugins are deleted.
What if one of these deleted plugins had an arbitrary options update vulnerability?
Can I be sure that deleting plugins is actually enough?
Other than the bloat that it adds to sites?

I think I gotcha now :slight_smile:

It says delete data - it won’t do it unless authors add a special method for it though. << Is that the problem?

Do you know what action it fires when you confirm then or would we expect cleanup to fire via standard deactivation hook?

That’s a terrible analogy. The consequence of confirming or not that is not terribly significant. But you seem to want to apply the same process used for relatively trivial decisions to mission-critical decisions. As I said before, that’s just misguided.

1 Like

So there are two hooks that are relevant here.
Well, actually three.

There is the activation hook.
Which is where best practice suggests you ought to be registering all your options, etc.

Then there is the de-activation hook.
This is a temporary state.
Best practice suggests that you ought not to be deleting any data here, but it can happen.

Then there is the uninstall hook.
This is supposed to “delete the plugin and all its data”.

You must de-activate a plugin before you can uninstall the plugin.

The plugin author is supposed to de-register all their options when the plugin is uninstalled, among other things.
Unfortunately, there are a considerable number who do not do this.

So, yes.

That assumes that everybody uses their site for the same purpose.
Deleting a plugin with custom logs for example IS a mission-critical decision for a significant number of business users.
One person can’t decide for everyone else when something is relatively trivial vs. when it is mission-critical.
They have the right to decide that for themselves.

I spot a straw man.

No-one is suggesting that they shouldn’t. You just want that decision to be made at a time that I think makes little sense. I think it should be made at a different time. That’s the true picture here.

1 Like

The strawman isn’t my creation…

More information on cleaning up upon plugin installation.

I find this part interesting:

A number of plugins create custom post types. It’s a smart move to flush the rewrite rules on activation to make sure users don’t get a 404 error when visiting a post from the new custom post type.

This is why there actually is a better solution, mentioned in the Codex in the documentation for the flush_rewrite_rules() function. In this solution we use the modularity of our functions to register the custom post type on activation separately:

The article mostly focuses on the how, with the why being a fundamental assumption.

Conclusion
If your plugin adds stuff to WordPress it’s your duty as a developer to remove it when the user decides to delete your plugin.
Using the activation, deactivation and uninstallation methods outlined here you can build a system which does this safely and securely.

The article below evaluates the pros and cons of uninstalling options vs. potentially valid reasons for leaving them.

Short answer: it can’t, and it shouldn’t try.

Right now a plugin can include any code it likes as part of its uninstall process (deliberately blurring the lines) and there’s nothing we can do about it.

The right solution is to borrow from Microsoft and the MSI installer - define state, not a procedure. State can be audited sanely, procedure cannot.

There’s a lot of work involved in that, so v3 earliest.

In the meantime, guidelines are the way to go, with a warning that we’ll flag plugins and themes that persistently get it wrong.

2 Likes

Short answer: it can’t, and it shouldn’t try.

Ummm… you maybe want to also share the not so short answer as well for posterity.