[wp-hackers] A third action for plugins

[Jacob]

Well, the patch needs to encompass, the following.

*User Interface*

In wp-admin/plugins.php:

1. There needs to be a link or button that says uninstall, which pops up 
a dialog asking if the user would like to uninstall (using Jeremy Clarke 
Text). There are two actions, an Accept, and a Deny.
2. Accept Action: If the user clicks "Yes", then by method of AJAX or 
going to a new URL, the <?php $success = 
apply_filters('{PLUGIN_LOCATION}_uninstall', null); ?>. Follow $success 
explanation (#4).
3. Deny Action: Do nothing.
4. Check $success status, if null, then plugin does not support 
uninstall action and inform the user of that fact. If false, then the 
plugin failed to uninstall completely and inform User of that fact. If 
true, then uninstall succeeded, and inform the user that the uninstall 
was completed.

In wp-includes/plugin.php:

<?php

function register_plugin_uninstall($plugin, $callback) // Not exactly 
sure what the format is exactly.
{
    add_filter(plugin_basename($plugin).'_uninstall', $callback);
}

?>

Then it is completely up to the plugin author to take advantage of the 
feature. This would probably the easiest way to implement the feature. I 
believe that if a plugin author is well informed enough, that they 
should be able to undo whatever they did when this action is called. 
Since the interface will be right in the user's face, it is unlikely 
they will be able to miss it.

 Bonus points (not redeemable for anything of any value) for anyone that 
submits a patch that checks if the plugin has hooked into the uninstall 
and only disable the option if the plugin actually implements the hook.


Jeremy Clarke wrote:
> To backpedal a bit and vote for something described before, I think
> the best solution would be to include an 'uninstall' action seperate
> from deactivation that plugin authors can use to designate a complete
> removal rather than a temporary de-activation.
>
> If there is a function designated for the 'uninstall' action then when
> a user turns off the plugin they get a dialog that pops up and says
> something like:
>
>  "This plugin has created options that will not be used if it is
> turned off. Would you like to delete these options now? (select 'no'
> if you plan to re-activate this plugin in the future)"
>      [Yes, uninstall completely]   [No, keep options]
>
> I guess there's a bit of intentional complication of the options
> there, but it would avoid the 'ok/cancel' problem as people would have
> to read it before choosing a response. It also avoids cluttering up
> the plugins interface with something that all existing plugins and a
> lot of future plugins are likely to ignore.
>
> Jeremy Clarke
> http://simianuprising.com
> http://globalvoicesonline.org
>
>
>
>
>
>
>
>
>
> On Nov 26, 2007 6:30 PM, Paul Menard <paul at codehooligans.com> wrote:
>   
>> I like it! Yeah having some sort of trail in the options to know which
>> plugin created which row would be very nice. The only thing I can
>> think of for not serializing the plugin info is when the plugin uses
>> multiple options. Though I can see each of those options being
>> serialize-able.
>>
>> I guess I'm really answering the reply from the previous person. Some
>> plugins like cforms for example create many (more than 2) options.
>> This is generally better since each form is handled different. In
>> other words why load the entire data structure if your site has 10
>> forms when you only need one. Then again this structure could be
>> cached and not really see a performance issue. head spinning. I need a
>> beer!
>>
>> P-
>>
>>
>>
>> On Nov 26, 2007, at 4:54 PM, Stephen Rider wrote:
>>
>>     
>>> Just a thought --
>>>
>>> Would it be possible to modify the add_option function (and related)
>>> so that if a plugin adds a non-serialized Option-A, the function
>>> will say "this option is being added by Plugin XYZ" and
>>> automatically serialize it under plugin_XYZ_options[Option-A]?
>>>
>>> This could be made backwards compatible by checking if an
>>> unserialized Option-A exists already, and convert it the first time
>>> it is called or modified.
>>>
>>> Are there any situations we can think of where a plugin option _must
>>> not be_ serialized?
>>>
>>> Stephen
>>>
>>> On Nov 26, 2007, at 3:54 PM, Benedict Eastaugh wrote:
>>>
>>>       
>>>> Secondly, plugins can be very untidy and save a bunch of different
>>>> options all over the options table, which is probably one of the
>>>> reasons people feel the need to clean up the database. Once one
>>>> starts
>>>> providing a lot of options, a better way to do it might be
>>>> serialising
>>>> them and saving them in a single db entry.
>>>>         
>>> _______________________________________________
>>> 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
>>
>>     
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>   


-- 

Jacob Santos

http://www.santosj.name - blog
http://wordpress.svn.dragonu.net/unittest/ - unofficial WP unit test suite.

Also known as darkdragon and santosj on WP trac.