[wp-hackers] A third action for plugins

[Jeremy Clarke]

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
>