[wp-hackers] register_uninstall_hook VS uninstall.php

Davit Barbakadze jayarjo at gmail.com
Sat May 8 07:35:20 UTC 2010

That was vast :)  Flash-back into the history behind such solution was great
too :)

But I think it's confusing for everyone, who is trying to use it without
reading the core. In my opinion it means that it needs some improvement,
register_uninstall_hook part, I mean.

On Sat, May 8, 2010 at 5:53 AM, Jacob Santos <wordpress at santosj.name> wrote:

> "The plugin should not run arbitrary code outside of functions, when
> registering the uninstall hook. In order to run using the hook, the plugin
> will have to be included, which means that any code laying outside of a
> function will be run during the uninstall process. The plugin should not
> hinder the uninstall process."
> *Explanation*:
> I'm not sure what the confusion is of this and from what Dion stated. I'm
> basically going to restate what he had said earlier. However a little
> history.
> *History*:
> When the hook is used, the plugin is deactivated. In fact, in 2.7 and I
> will
> assume in later versions, the plugin has to be deactivated to be
> uninstalled. Therefore, if you are running code outside of functions, then
> this will run when the plugin is uninstalled. Most of the time, the code
> won't affect anything and should be "safe" however, during the development
> of the solution, a lot of compromise and elitism went into the patch.
> Really, I had no idea nor I believe anyone else had the best way to do it.
> The hook seemed like it would be "best" and the file based alternative was
> added later to satisfy some base concerns either I had or other people or
> both. It has been a long time since that patch was applied and I'm not
> going
> to read through what other people and I wrote. Not all of which is on that
> ticket [1].
> *Back to Explanation*:
> Simply, the point of the statement is to let you know that you should
> *never* run code outside of functions and class methods. During that time,
> I
> noticed that a few plugins were including code that was run in the "global"
> scope and thus was causing problems when the "global" scoped switched to
> "function" or local scope. Since the uninstall hook is function / local
> scope, any "global" scope code will need to be defined as thus:
> 10. global $my_global_variable;
> 20. if( conditional() ) {
> 30.     $my_global_variable = 'womething';
> 40. } else {
> 50.    $my_global_variable = 'widget';
> 60. }
> function uninstallhook() {
>   global $my_global_variable;
> }
> The problem is that unless 10 is in the code, the uninstallhook won't
> function properly and it was a fear that people would incorrect assume that
> the fault was WordPress when it was in fact the crappy [2], poorly coded
> plugin's fault.
> *Conclusion*:
> So basically the comment, and I guess it was a little vague, is just to say
> that if you do the above that it is up to you to ensure that your code
> works
> when in function / local scope when the uninstall hook is called. The
> second
> point is that you shouldn't be running anything other than the uninstall
> hook anyway. If everything is in functions, then this will be fine since
> only the uninstall hook function and its helpers will run.
> The second point also includes security. Basically, your code is being
> deleted and the reason for the uninstall process in the first place. To
> allow for you clean up any tables, metadata, files, etc that you created
> during the plugins run and activation. That is it. It does not allow for
> any
> special cases and if that is what you are asking, like, "Well, I want a
> screen where they are asked if they want to keep their data." Then guess
> want, that has already been debated and while it can be brought up again
> for
> a future patch it was decided that it just wasn't going to happen by the
> powers that be. I, alas, do not know if that is already possible since it
> has been a year since I looked at any improvements.
> I do think that the uninstall.php is the best method for uninstalling,
> since
> it gives you full access to the WordPress library (admin + core) and is, in
> my opinion, cleaner when writing than using a function which will most
> often
> be mixed in with a lot of other misc functions. Please note that the define
> is only defined for the file (unless this was corrected, I'm going off the
> original implementation) and not for the hook, so it should only be checked
> for the file in uninstall.php and not the uninstall hook.
> [1] I don't know WTF that ticket is, it appears some "improvements" / fixes
> that require additional fixes went into a relatively simple process. It
> isn't the ticket I'm references earlier and hopefully won't be confused
> with
> the initial uninstall patch and ticket. I'm unsure why two functions are
> even required during the uninstall hook process. The primary hook should be
> calling other functions that run processes for uninstalling instead of
> cycling through a series of functions. This seems like a bug with the
> plugin's code than a bug in WordPress codebase, unless it allows it, then
> it
> should only allow one function regardless.
> [2] I'm not sure, but I mean the other more obscene curse word, but I'm not
> sure if that is "cool" so I'm going to play it safe... well, safer than
> just
> not including it.
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers

Davit Barbakadze

More information about the wp-hackers mailing list