[wp-hackers] register_uninstall_hook VS uninstall.php

[Andrew Nacin]

On Fri, May 7, 2010 at 2:09 PM, Davit Barbakadze <jayarjo at gmail.com> wrote:

> Unfortunately I can't use uninstall.php for my purpose. Or better to say it
> would be kinda last resort.
>
> I read the code now and understand what you mean... But, I still find it
> pretty weird. Isn't it? Why would you need to store callback in the
> database? Or why would you need to call it directly? Why not just to do
> do_action('uninstall_' . $file ... and let the user to hook on this and do
> whatever he/she finds appropriate? This could eliminate neccessity of using
> function_name callback only, and could have been much more cleaner, logical
> and convenient in general.
>
> Ok, whatever is the reason behind such solution I don't get, but even if
> there's one, I've found very nice workaround, which could work if only
> WP_UNINSTALL_PLUGIN would have been defined for register_uninstall_hook
> version too. Is there any reason why it's not?


When you plugin goes through the uninstall process, it isn't going to be
activated by that point. In most cases, it would have been deactivated well
before that page load, which means none of its code is included. Thus,
WordPress uses the option stored in the table to determine what file to
include and what code to execute. Hence why it must work this way, with a
function or a static class method. The rest of the plugin simply will not be
loaded.

WP_UNINSTALL_PLUGIN is only designed for uninstall.php, that way that file
is not unintentionally included or hit with an HTTP request and the
uninstall procedure is run. It's no different from dying at the top of
certain files (such as edit-form-advanced.php) if ABSPATH is not defined.

Hence, you can use uninstall.php, the same way you can use the uninstall
hook, in most cases. In both cases, the PHP code you are running may be
blissfully unaware of anything else your plugin normally does on
initialization.