[wp-hackers] register_uninstall_hook VS uninstall.php

[Davit Barbakadze]

Ok, I understand now what you are doing, but it doesn't answer question -
why.

> In both cases, the PHP code you are running may be
> blissfully unaware of anything else your plugin normally does on
> initialization.

I'd like it to be aware at some extent.

Ok, I will tell you what my workaround was. Since register_uninstall_hook
does include my plugin main file I can execute some code and obviously do
add_action('uninstall_' . plugin_basename(__FILE_), array($this,
'on_unistall'), 0); too, right? If I knew prior to that that it is uninstall
procedure going on I could break execution here (having initialized whatever
I would need later when action will be called) and wait for an action. Then
I could remove default action (my action has higher priority) and do
whatever I need. WP_UNINSTALL_PLUGIN could have helped here a lot.

Do you find any issue with my solution?

The only thing is that I need to know that uninstall is happening and not
just some regular load.

So far I've found only one way to do this - check for: $_POST['action'] ==
'delete-selected'  &&   $_POST['verify-delete'] == 1            &&
in_array(plugin_basename(__FILE__), (array)$_POST['check']).

On Fri, May 7, 2010 at 10:32 PM, Andrew Nacin <wp at andrewnacin.com> wrote:

> 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.
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>



-- 
Davit Barbakadze