Thanks,
David

That issue has been discussed here before: Uninstall, is there such a thing?

Not sure if there is a core uninstall hook planned.

I want to disable and remove the plug-in completely so that none of its options are left in the database.

I think there should be a way for plug-in developers to do such things.

So far I have a plug-in that erases all the info that it puts into the database and all user options but only problem is it comes with payload that if the user want to re-activate the plug-in they must also do all the config all over again. I think that is a reasonable approach to take.

Ideally there should be intermediate step in Plug-in Deactivation process, where by plug-in developer like myself can intercept and alert the user to if they want to make a back up of their options. before de-activating the plug-in.

What do you think?

@Lloyd,
I see what you mean, but I’m not trying to give a tutorial on actions/filters with this article. Perhaps I should write one here?

The various methods should hopefully show plugin authors the various possibilities so that plugin deactivation issues can be a thing of the past.

Your 1,2,3,4,5,6 presentation may confuse people a little about the difference between actions and filters though (semantics really, as they share the same code and execution). 6 should really be with the other action information and is likely the scenario that it is worth providing some real examples for.

Your filter example is completely forced. Filters are always in the context of manipulating existing data, whether provided by core or a plugin, and very unlikely to relate to plugin deactivation issues.

As I started awesome content to put other there for critique


if (is_plugin_active('pluginbasedir/pluginfilename.php'))
add_action('my_related_posts', 'related_posts', 1, 1);
else
// do something else