Many plugins do not clean up after themselves. Some plugins include an option to delete data. Many times I’ve looked at databases to find WooCommerce tables with no plugin installed, or Gravity Forms tables with no plugin installed. Users use or test a plugin, it creates tables, and then data stays in the database forever basically. Most users don’t even know it’s there.
In a discussion about trialware plugins, Tim brought a good point that made me think about this more:
This applies to all plugins. The data will stay in the database after plugin deactivation and users might think it was deleted. This could apply to Classic Commerce.
So cleaning up data should be something we consider seriously.
Possible implementation
There are 2 possible solutions, I think:
Require plugin developers to include the data deletion option in their plugins if they want to be listed in the directory. This means plugin reviewers would need to check for this code.
Implement data deletion into the core and ask users if they want to delete data or not during the plugin deactivation process. So when user clicks on “Deactivate” option, they would see a prompt that asks them “Do you want to delete all associated plugin data? Selecting Yes will permanently delete all plugin data. If you’re troubleshooting and plan to reactivate plugin, select No.” Something like that.
The prompt is my preferred option, hence the petition. This is because option 1 still doesn’t guarantee user knows to use that option in the plugin. The option 2 does ensure the user knows they can delete the data and also serves as a reminder that there is data associated with the plugin.
The exact implementation depends on the core’s handling of the database tables created by plugins. I don’t know exactly what it does or doesn’t do. If the core can identify tables/options created by the plugin, then we can delete them if user chooses to do so. If the core doesn’t track this right now, we would need a way to track what plugins create inside the database. Maybe plugins could declare tables and options they create (could be a requirement) by saving a list in the database or providing a list as an array, so the core could use it to delete data if necessary.
Would love to hear what others think, get the discussion started on this.
Regarding #2 – as a plugin developer, and inline with well-established *Press practices, I think deactivation should not delete data, unless that is an actual option in the plugin’s own settings and the user has opted into it willingly. Deactivation is primarily used when troubleshooting and the last thing a frustrated (or panicked) user needs is more dialogs and text to wade through.
Also, in the case that the user was deactivating the plugin with further intent to then delete the plugin, the user would be prompted twice in a row about deleting data. This is needless.
When the plugin is deleted, that is the appropriate time to prompt the user about deleting data.
Long story short: it’s a no from me on this petition.
In order for this to be implemented we would need to add a requirement to any plugins listed in our directory. Your proposed solution (1) would require all plugins to implement their own cleanup routine, and option (2) would require all plugins to provide a list of data that needs to be deleted, as you say.
I suspect the best path would be some intermediate option, where ClassicPress provides a standardized hook and maybe a few functions for plugin authors to list data that should be deleted and/or provide custom code that will finish deleting any non-standard data.
However, I also think that making this a hard requirement is likely to cause more problems than it solves. Currently you can (usually) deactivate or remove a plugin and then reinstall it later without losing your settings, and (usually) the data that is left behind does not cause performance or other issues with the rest of the site. This won’t be true for all plugins, so the plugins that do have this concern should implement their own cleanup routines.
There is also the fact that we would have to require mandatory updates for basically all plugins in our directory, which is not likely to succeed.
If there’s a hook for that, then yes deletion action would be more appropriate.
I think this could be a good approach. We should at least require (or at least strongly recommend) plugins that handle personal information that may be subject to GDPR to include an option to delete data.
