[wp-hackers] register_uninstall_hook VS uninstall.php

scribu scribu at gmail.com
Sat May 8 07:03:12 UTC 2010

On Sat, May 8, 2010 at 9:42 AM, Davit Barbakadze <jayarjo at gmail.com> wrote:

> Ok, what I do is I have my small framework, from which I inherit my all new
> plugins. My friends are using it too, so I needed a simple, transparent way
> to clean up after plugin, when it gets uninstalled. Of course I could tell
> guys to do a particular things in uninstall.php, but big part of logic is
> encapsulated in parent class, so they will need to look in there and check
> what the names and namespaces are and come up with static names, which they
> will need to use in uninstall.php. It's not that hard of course, but I
> rather automate this somehow. Of course I probably could include my plugin
> from uninstall.php and do some cleaning from there, but among other things
> it adds complexity and clutters plugin directory too. At least I will have
> to explain to everyone - guys you do not need to touch that uninstall.php
> in
> root directory or something. Then if I could have just a regular class
> method that does uninstall it just could have been so much more logical - I
> think that's what people expect anyway.

That's my use-case exactly.

But anyway, I think my solution is pretty clean by now, I still use an API
> right? It won't harm anyone if I remove default action and run my own? If I
> could get rid of ugly: $_POST['action'] == 'delete-selected'  &&
> $_POST['verify-delete'] == 1            &&
> in_array(plugin_basename(__
> FILE__), (array)$_POST['check']) it could become
> even cleaner I think.

Try this:

// Have more than one callback attached to the uninstall hook
function add_uninstall_hook($plugin, $callback) {
	// trigger $is_uninstallable_plugin flag
	register_uninstall_hook($plugin, '__return_false');

	add_action('uninstall_' . plugin_basename($plugin), $callback);

You use it exactly like register_activation_hook().


More information about the wp-hackers mailing list