I thought I did - I see the rest of my post, do you not?
I see more content in the post but not the long answer or your other thoughts on the discussion.
No, those are both, but maybe some glue will help.
If we try to force plugins to clean up we will create a bigger mess; partly because that code will be the least tested, and partly because we canât sanely check it.
Apologies, I assumed the entire post was your short answer. Sorry for my misunderstanding. I intended no offence.
I agree that we should try avoid any forcing of this but I would like for us to at least gently nudge them (via an education campaign) to employ their own cleanups where appropriate 
I completely support adding âclean up after yourselfâ to the guidelines, but it canât be part of the rules; Iâd rather a plugin didnât try to clean up than do a bad job and break other things.
2 Likes
when you uninstall a plugin that plugin should clean all, but many times some users if they want to update a plugin they have locally saved somewhere, they delete and reinstall the plugin. Then they realize they have lost all the options.
Even if this is not the right procedure, many times it happens.
For me, the best way is having a pop-up provided by the core that asks what to do after removing the plugin, if the user decides to clean all the file uninstall.php is called, in another case nothing should happen. This decision should be taken by the user, not by the plugin author and the core should provide the pop-up. The plugin authors should just write the code in uninstall.php to clean the database as they do now.
If the file uninstall.php doesnât exist or itâs empty the core should warn the users that nothing was cleaned.
In an ideal world before the plugin activation, the core should also check the file uninstall.php, if itâs empty or doesnât exist the plugin canât be activated and the user will see the notice âSorry this plugin canât be activated because after removing it we would not know what to do with its options âŚâ or something similar. Then surely the plugin authors will at least write someting in uninsall.php.
5 Likes
You canât rely on the existence of an uninstall.php file for cleanup activities. A lot of plugins use an object-oriented static method to keep the plugin root tidier.
1 Like
This must change. The plugins have to respect uninstall.php. If you donât put some limits and force a little of standardization, how can you manage this mess? Now every plugin does whatever they want after plugin removing. The uninstall.php file would be an easy way for the core to check.
If you donât agree about standardization, letâs stop to loose time speaking about clean-up.
1 Like
Core provides 2 ways to perform uninstallation activities (uninstall file or static method). Iâm not talking about anything that isnât API compliant.
Supports both, but recommendation from WP is to use uninstall.php
According to the official Plugin Developer Handbook, both are recommended. The handbook actually shows the hook method as the very first example, followed by the the uninstall.php method.
When I was doing rewrites I looked it up and something I found stated that uninstall.php was the recommended method. Iâll see if I saved a link.
Agree, that pop-up is not the right choice. Also agree, that a complete uninstall, erasing all data, is not a solution.
From my point of view the whole discussion can be solved by UI changes.
The solution can be additional menu page under âPluginsâ, named âLegacy settingsâ or something similar. When user uninstalls a plugin, settings can be stored and a corresponding record is made in âLegacyâ page. User can review them at any time and choose what to keep for the future, what to delete completely. Managing all legacy data from the one settings page.
This will achieve total control of plugin data and it will be done in the most user friendly way.
Now, Plugin Garbage Collector does something similar, but not in the inexperienced-user-friendly way.
Okay.
So you have a vulnerable plugin.
Confirmed zero day vulnerability.
The vulnerability relates to an option that it registered upon install.
The plugin is easily replaceable.
Which solution do you propose to this scenario?
Delete the vulnerable plugin.
Install a replacement.
If like a replacement - delete the data of the vulnerable plugin.
If not - install the old plugin, when vulnerability is fixed. In most cases, no configuration is needed, because data and settings are saved.
How do you find all of the options registered by the old plugin?
How do you find all the custom tables (this should probably be the easiest).
How do you find all the related meta data?
âLegacy dataâ under Plugins menu
Yes, this should be added to the core function. I assume, when a plugin is activated, core knows what tables, meta, options plugin creates, can mark them and upon deletion of the plugin, move to the âLegacy settingsâ menu.
Sorry, if I said something stupid from the technical side - I am not a developer. UX and UI is my specialization.
Just deleting the plugin could have the same effect as not taking any action at all.
That is the problem.
Users assume they are now safe, but they may not be.
That is exactly the problem.
The plugin author needs to register these.
Core doesnât know by itself.
At least not with the way things work currently.
It means we have a problem and we should address it. Sorry, I can help with UI, not with code.
But can you explain to me, non-coder how setting data and tables left after uninstallation can be vulnerable? No php, nothing, just data.