[wp-hackers] register_uninstall_hook VS uninstall.php

[Jacob Santos]

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
>>
>>      
>
>
>