I was on an old site and noticed that a lot of the old plugins that I uninstalled did not clean up after themselves.
(I.e. custom tables and data remained after they were deleted.)
How can the plugin directory rules deal with this?
(Edit: For some plugins it may also be a problem of using TRUNCATE instead of DROP
I have often wondered of ways to enforce a cleanup routine on removal but after thinking several times I have never been able to figure out a way to detect what specific cleaup was needed in a generic way. Some plugins store only in the options table with a prefix but others use custom tables and I have seen it a few times too often often where they’re storing data without any prefixing to target at all 
.
We need to encourage plugin authors to add this routine themselves as only they know immediately how to clean up their data. As a last resort core could provide a generic cleanup mechanism, it may not be 100% accurate but still better than nothing.
I think we need to figure out how to effectively incorporate this as a plugin directory requirement.
Not sure what the right way is to incentivize it though.
Agreed 
One thing I think we could do that would not necessarily need any added requirements would be to embark on an education campaign to teach developers the ways to store data so that it’s easily identifiable (and in turn removal or retrieval for export of desired information becomes easier).
I do not know if a good incentive to offer developers which would encourage them to include proper cleanups in there offerings but I do believe many of them would not need any incentive beyond knowing that there are doing things in the best interests of their end users. I’m aware this is a bit of an evengelistic viewpoint and that in the real world sometimes people are not so big on helping end users delete their plugins data lol
Speaking of incentives… the more rules that are added, the more incentive developers have to not bother with it and just continue to use the WP repo, which will probably be a viable option into the foreseeable future.
To be clear, I do support writing self-cleaning plugins – in fact, it’s one of my value propositions – however, I feel this is an area of guideline, not rule.
I agree with this 100%. In fact, I think it would be very dangerous to require that plugins delete everything that they have stored in the database.
Imagine the situation of a user who finds something has broken. S/he panics, and deletes the plugin s/he guesses might be responsible. Now a minor problem has potentially become a disaster, because all the stuff that s/he needed, that was previously stored tidily in the database, gets deleted. Yes, s/he might have a backup, but there’s no way to know that.
So I’d be absolutely opposed to requiring that plugins delete all the data they recreate when they are themselves deleted. A better way to do this, in my view, is to encourage plugin developers (a) to explain what data their plugins create and store so that users have an opportunity to understand the issue, and (b) to provide an option that requires an affirmative decision by a user to have all such data deleted on plugin deletion. But the default would normally be to leave the data where it is.
@Code_Potent
You know I am all about encouraging voluntary compliance… 
Personally I support a screen when deleting that asks whether you want to delete options and custom data.
I would also support a pop-up type message that asks whether you are sure you want to do this and which reminds you of the importance of keeping regular back-ups.
I don’t support the use of pop-ups either. They are bad for accessibility. I also don’t support users being offered that choice at the point of plugin deletion. That’s when they’re likely to be in a panic.
I prefer the way that plugins like s2Member do it. They have a setting that defaults to keeping plugin-created data, but that setting can be changed at any time so that the data will all be deleted on plugin deletion. This is better because the user is much more likely to make the decision when calm, and not when panicking because something has “broken their site”.
I’m more inclined to add an admin option (checkbox) to “Delete this plugin’s data when the plugin is deleted”
It’s not the plugin author’s responsibility to remind site managers about important things that are irrelevant to the task at hand. There are myriad “important” items that someone might be reminded of – deleting inactive plugins, forcing strong passwords, etc – the uninstall process just isn’t the place for it.
I am fine with that too.
And, perhaps it is worth noting the context of this…
I am talking about plugins that created six to eight custom tables each.
And plugins that created on average between 20k and 50k rows per custom table.
And which did not have option settings on the plugin page relating to deleting preferences.
To encompass the full context of clean-up, though, you have to consider that custom tables are just a single aspect. There may also be options, metadata, images, custom post type data, etc. to think about.
Jip. Indeed. I agree.
I was commenting as I was working on something, so the aspects that were directly visible during that specific process were the ones I addressed here.
I do not mean to exclude any others.
Also, there are a number of applications for which I greatly prefer custom tables, so I am not bad-mouthing them.
For a great many aspects, it is almost impossible to create “rules” for plugins because they are all relative to the purpose and nature of the plugin.
When I say “directory requirements” I mean submission requirements, which for me include best practice.
I would say that there is a distinction between the way that I think of user-generated data, vs. automatically generated data vs. data that is not customized.
Data which is not customized to the site in my mind can be safely deleted (and in my mind, SHOULD be), as re-installing the plugin would fix the issue.
Sane defaults that are never written to the database is one of the ways I see developers use to help with a minimal need to store data and that data that does get sorted is data users customised. I like that approach but it may not scale well for anything handing more that a dozen or so options.
This is the current default WP behaviour.
Trying to understand your argument.
Why is that bad for accessibility? 
Not to speak for somebody else but popups and modals are often not A11Y friendy because they take the users focus away from the document flow and that is hard for screen readers to catch without the modal also handling browser focus events. I don’t know a lot more about the technical details of it but if a bit of time is invested to building it out it could probably be accessible.
Am I the only one who has ever accidentally clicked a link on a page I did not mean to while moving the cursor? 
No “Are you really sure you want to do this?” messages would mean I would be in crisis mode a lot more often.
Exactly. Accessibility always requires that everything can be accessed easily from the keyboard. This is important primarily for those with poor fine motor control and those with significant visual impairments who rely on screen-readers.
There are typically big problems being able to control the cursor from the keyboard with pop-ups. So it might be difficult to respond properly, or the user might be left not knowing where s/he is on the page.
No, you’re not. Now imagine you’re blind, and you might have some idea of the problems this type of thing causes.
One other thing: CP is business-focused. Businesses and public institutions are under legal obligations in many countries to ensure that their websites are accessible. So it’s really important that we ensure that WP is accessible. Otherwise those organizations won’t be able to use CP. We have already seen that they refuse to use Gutenberg for precisely this reason.
So which alternative do you propose?
Not having a check before deleting something is not something I personally consider an option.
But not sure what other viable alternatives there are.
I support including an admin option in the plugin’s settings, defaulting to keep data, that will enable the user to choose to have the plugin delete its data when it is itself deleted.
This would not become a decision to be made when the plugin is being deleted, though. It’s just one of the plugin’s settings.
I whole-heartedly support an admin option in this regard.
However, this does not solve the problem that people may accidentally delete a plugin, without any way to stop the process once it starts.
I cannot support that.
What I would support instead is being re-directed to the plugin’s settings (to review the options) once the “delete” link is clicked on the list of plugins.
The plugin can then be deleted once the choices have been confirmed by clicking a button.
That would serve everyone’s needs.