[wp-hackers] register_uninstall_hook VS uninstall.php

[Davit Barbakadze]

Jacob, guys, I think you overcomplicate things. scribus solution  (above) is
very simple and clean, it doesn't add any load. My solution is very similar
to his, but I just remove default hook and use my own. The only thing I was
wondering about, was whether there is any reason why WP_UNINSTALL_PLUGIN
couldn't be defined for both uninstall approaches.

In fact, I think storing callback in database is much more nightmerish, then
whatever I or scribu have suggested.

On Sun, May 9, 2010 at 6:44 AM, Jacob Santos <wordpress at santosj.name> wrote:

> I don't think anyone knows specifics of what you need. What you describe
> seems to be that your plugin is full of WTFs and nightmare-ish, but I'm most
> likely wrong. You probably have an awesome system that eases the development
> of plugins a great deal. This one thing is hindering you since it does not
> fit nicely in to the way you developed the plugin and wish to implement
> something that is external and don't really know how to quickly and easily
> do so without refactoring either your code or the WordPress code. I judge,
> it is one of my flaws and it is compounded by being wrong a lot.
>
> The truth is, I have not seen your code, nor do I quite frankly care to see
> your code. Dion might or Andrew or anyone else that might have replied. If
> it would help you, then I'm sure someone in the community would step up and
> do so. However, speaking only for myself, I do not believe a patch is
> warranted for your specific use case.
>
> Honestly, probably the best "fix" would be to remove the requirement that
> the callback is added and add just the file to the database instead. It
> would then be up to the plugin to set the hooks that are run for the
> uninstall. This would hopefully, solve your problem and would solve scribu
> problem as well. I'm not quite sure why it is even there in the first place
> other than redundancy to ensure that the uninstall hook is called and to
> correct any other cases where the hooks would not be set when the file is
> included, if the developer was expecting hooks to be called. If that was the
> case, then it was just being lazy and not wanting to test any use cases that
> wouldn't work without the redundancy. It is something that could be removed
> once full testing is done.
>
> Well, I do remember that with development, WordPress shouldn't hinder the
> methodology of the plugin, even if, technically, the plugin developer is
> wrong. The above solution wouldn't be difficult and my estimate would be
> that it would take 10 minutes. However, testing it would take about an hour
> or so and I'm not up for that. Have fun!
>
> Just FYI, classes can still be used, the method would just be static. I
> have stated this before, but I might not have been clear. Also, there is
> nothing wrong with using functions. The uninstall process is best separated
> from the rest of the plugin code, which is why most system programs have an
> separate application that uninstalls the main program.
>
> Jacob Santos
>
>
>
> On 5/8/2010 2:30 PM, Davit Barbakadze wrote:
>
>> I'm not going to use it for something else. I described my problem above.
>> It
>> is that I use variables in options and table names, and it would be a
>> duplicate work to redefine the whole logic in uninstall.php. I just do not
>> see a point why I shouldn't be able to use the logic I already have (and
>> use
>> OOP approach and not that ugly function namespacing). And then there is
>> some
>> support built-in already, like calling callback with an action instead of
>> calling it in some other way. Why not to make this support more
>> conssistent
>> and convenient.
>>
>> On Sat, May 8, 2010 at 10:55 PM, Andrew Nacin<wp at andrewnacin.com>  wrote:
>>
>>
>>
>>> On Sat, May 8, 2010 at 2:43 PM, Davit Barbakadze<jayarjo at gmail.com>
>>> wrote:
>>>
>>>
>>>
>>>> Well, thanks :) Although I think that's the case when an API is faulty
>>>>
>>>>
>>> and
>>>
>>>
>>>> needs some improvement. Is it so hard to remove WP_UNINSTALL_PLUGIN
>>>> definition from conditional?
>>>>
>>>>
>>>
>>> It isn't, but it wasn't the point of the constant. The point was to
>>> provide
>>> a safeguard for uninstall.php, not to allow the same callback to be used
>>> for
>>> both an uninstall routine and something else.
>>>
>>> You're welcome to open a ticket for it for>  3.0.
>>> _______________________________________________
>>> wp-hackers mailing list
>>> wp-hackers at lists.automattic.com
>>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>>
>>>
>>>
>>
>>
>>
>>
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>



-- 
Davit Barbakadze