[wp-hackers] A third action for plugins

[Paul Menard]

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