How do you store multiple plugin options

Everybody knows, or at least should know, that storing every variable
as an option is a bad idea. You usually use an array and store the
array.

How do you store multiple options.
What I mean is, you can have general options, options that are to be
used throughout the plugin. You can have default widget options, so
when you don't enter a value in the widget this option will be used.

Currently I store this as follows:
$general=array('key1'=>'value1', 'key2'=>'value2');
$widget=array('key3'=>'value1', 'key2'=>'value4');
$option=array('general'=>$general,'widget'=>$widget);
update_option( 'myplugin', $options );

I also can see it as follows:
$general=array('key1'=>'value1', 'key2'=>'value2');
$widget=array('key3'=>'value1', 'key2'=>'value4');
update_option( 'myplugin-general', $general );
update_option( 'myplugin-widget', $widget );

So how do you store your options?

On Wed, Mar 24, 2010 at 1:06 AM, Peter van der Does
wrote:

> Everybody knows, or at least should know, that storing every variable
> as an option is a bad idea. You usually use an array and store the
> array.
>
> How do you store multiple options.
> What I mean is, you can have general options, options that are to be
> used throughout the plugin. You can have default widget options, so
> when you don't enter a value in the widget this option will be used.
>There's no point in storing default widget options (that never change) in
the wp_options table.

Just leave them in the code:

function widget($instance) {
    $defaults = array('
        key => value
        ...
    );

    $instance = array_merge($defaults, $instance);
}

On Mar 23, 2010, at 7:36 PM, scribu wrote:
> There's no point in storing default widget options (that never change) in
> the wp_options table.
> 
> Just leave them in the code:
> 
> function widget($instance) {
>    $defaults = array('
>        key => value
>        ...
>    );
> 
>    $instance = array_merge($defaults, $instance);
> }+1. Defaults stored in code are much less fragile and it becomes much better documentation.

Also, similarly, it sure would be nice if there was a standard way for plugins to on-demand persist their option state to code so that people who develop and deliver a site can include said code to reinitializes all plugins from a default install. It would make deploying developed WordPress solutions easier and would make reinitializing WordPress solutions during development much easier.  Thoughts on this?

-Mike

On Mar 23, 2010, at 6:47 PM, Mike Schinkel wrote:

> Also, similarly, it sure would be nice if there was a standard way for plugins to on-demand persist their option state to code so that people who develop and deliver a site can include said code to reinitializes all plugins from a default install. It would make deploying developed WordPress solutions easier and would make reinitializing WordPress solutions during development much easier.  Thoughts on this?Recommended reading:
<http://wpbits.wordpress.com/2007/08/10/automa...>

custom install.php == awesomeness

On Mar 23, 2010, at 7:58 PM, Stephen Rider wrote:
> On Mar 23, 2010, at 6:47 PM, Mike Schinkel wrote:
>> Also, similarly, it sure would be nice if there was a standard way for plugins to on-demand persist their option state to code so that people who develop and deliver a site can include said code to reinitializes all plugins from a default install. It would make deploying developed WordPress solutions easier and would make reinitializing WordPress solutions during development much easier.  Thoughts on this?
> 
> Recommended reading:
> <http://wpbits.wordpress.com/2007/08/10/automa...>
> 
> custom install.php == awesomenessGreat link, thanks!  Now the next step would be to automate the automation with a hook for plugins called something like 'make_install.php' that could contribute code to an install.php itself based on its current state.  I'm envisioning an admin page where I could copy the generated install.php and past into a file, not something that would automatically overwrite the existing one.

-Mike

On Wed, 24 Mar 2010 01:36:45 +0200scribu  wrote:


> There's no point in storing default widget options (that never
> change) in the wp_options table.
> 
> Just leave them in the code:
> 
> function widget($instance) {
>     $defaults = array('
>         key => value
>         ...
>     );
> 
>     $instance = array_merge($defaults, $instance);
> }
> 
>But people can change the default value :-)
For example: The title of the widget. If you have multiple widgets the
user should be able to change the title for every widget without having
to change the title in every widget separately.

A better example would be my AVH Amazon plugin. It makes calls to
Amazon but it allows you to make calls to Amazon locales(.ca, .fr etc).
So instead of having the user enter the desired locale per widget, they
can enter it in the admin section.

On Tue, Mar 23, 2010 at 6:06 PM, Peter van der Does
 wrote:
> Everybody knows, or at least should know, that storing every variable
> as an option is a bad idea. You usually use an array and store the
> array.
>
> How do you store multiple options.
> What I mean is, you can have general options, options that are to be
> used throughout the plugin. You can have default widget options, so
> when you don't enter a value in the widget this option will be used.
>
> Currently I store this as follows:
> $general=array('key1'=>'value1', 'key2'=>'value2');
> $widget=array('key3'=>'value1', 'key2'=>'value4');
> $option=array('general'=>$general,'widget'=>$widget);
> update_option( 'myplugin', $options );
>
> I also can see it as follows:
> $general=array('key1'=>'value1', 'key2'=>'value2');
> $widget=array('key3'=>'value1', 'key2'=>'value4');
> update_option( 'myplugin-general', $general );
> update_option( 'myplugin-widget', $widget );
>
> So how do you store your options?I discuss some of this in my Settings API tutorial:
http://ottopress.com/2009/wordpress-settings-...

But, in general, the way you want to do it is as follows: Anything
that you will load all the options for at once (presumably because
you're using all or most of them) should be in one single option. The
majority of plugins should put all their options in one field, for
simplicity. Only rarely do you actually need extra options fields.

The format of that option's value is up to you, but I recommend
against nested arrays in the way you're suggesting there, and would
say a simple array would be better. Simple array lookups are faster
than nested arrays are, and with prefixing of your keys, it's really
just as easy to use.

So instead of this:
$general=array('key1'=>'value1', 'key2'=>'value2');
$widget=array('key3'=>'value1', 'key2'=>'value4');
$option=array('general'=>$general,'widget'=>$widget);

I'd say to do this:
$option=array('general-key1'=>'value1', 'general-key2'=>'value2',
'widget-key3'=>'value1', 'widget-key2'=>'value4');

-Otto

Storing database variables in an array should be considered a bad practice. Doing this is as an convenient  hack that shortens plugin design but has significant consequences.

Serialized data in the blog options table denormalizes the database. ReCaptcha uses one blog option setting called reCaptcha. If I want to update the keys across all my blogs in a wordpress MU install, I can not do it via SQL alone, I have to write a php plugin to tinker with the values. (Yes, I know reCaptcha has MU installation option and configuration file). Where I could have help from a DBA to fix something, I now need a developer.

Denormalization also means I couldn't have any systems integration or monitoring on database values without custom plugins. Other programming languages such as Java or Ruby don't have the same serialization functions PHP does, so any other development work that may need access to Wordpress data is restricted to PHP.

There are autoload features of blog options tables which many plugins are not taking advantage of.

There may also be performance penalties to serializing and deserializing arrays all the time that cause performance problems on high traffic sites.

Correct practice should be to avoid serialized arrays where possible and use proper prefixing in blog options to avoid collisions with other plugins.

On Wed, Mar 24, 2010 at 12:56 PM, Potkanski, Jason
 wrote:
> Storing database variables in an array should be considered a bad practice. Doing this is as an convenient  hack that shortens plugin design but has significant consequences.Many people disagree with you on this. I'm one of those people.

Serializing your options is not a "hack". It's the preferred method. Why?
- Speed: Pulling one row out of the database is faster than pulling
dozens of them.
- Simplicity: Having my options all together makes them easier to
reference instead of having dozens of get_options calls.
- Ease of design: Making settings pages which all use similar options
is easier this way. No need for dozens of "register_setting" calls,
dozens of slow get_options calls hitting the memory cache or the
database, reduced numbers of SQL queries, etc.

> Serialized data in the blog options table denormalizes the database. ReCaptcha uses one blog option setting called reCaptcha. If I want to update the keys across all my blogs in a wordpress MU install, I can not do it via SQL alone, I have to write a php plugin to tinker with the values. (Yes, I know reCaptcha has MU installation option and configuration file). Where I could have help from a DBA to fix something, I now need a developer.

MySQL has search and replace capabilities which work very nicely,
actually, and they can search and replace inside serialized data just
as easily as they can in non-serialized data. You don't need a
developer to adjust things. Although it does strike me as rather
trivial to write php code which basically says "include wp-load.php;
$o = get_option('whatever'); $o['whatever'] = new value;
update_option('whatever',$o);"

> Denormalization also means I couldn't have any systems integration or monitoring on database values without custom plugins.

They're stored as strings. What's so hard about monitoring strings?

> Other programming languages such as Java or Ruby don't have the same serialization functions PHP does, so any other development work that may need access to Wordpress data is restricted to PHP.

Java has tons and tons of serialization stuff, actually. I suppose
you've never seen "implements Serializable"?

Admittedly, the syntax is not the same between the two, in which case
you could either implement a parser (google will find one for you
quickly), or you could switch the code to use a common interchange
format. Probably the easiest way would be to use JSON. Or perhaps XML,
if you swing that way.

> There are autoload features of blog options tables which many plugins are not taking advantage of.

Autoload defaults to enabled, so unless the plugin specifically
disables it for its own options, then it is taking advantage of it.

> There may also be performance penalties to serializing and deserializing arrays all the time that cause performance problems on high traffic sites.

Serialization is built into the WP core. ALL options in WordPress get
serialized and unserialized. If performance was a problem, then it
already would be.

> Correct practice should be to avoid serialized arrays where possible and use proper prefixing in blog options to avoid collisions with other plugins.

I disagree. Correct practice would be to store your options in a
single array as much as possible and to let WordPress handle the
serialization for you as necessary. Only separate options out when you
have a different load case for them (such as options you only need in
specific places and not every time, large options, etc).

-Otto

>> There are autoload features of blog options tables which many plugins are
not taking advantage of.

> Autoload defaults to enabled, so unless the plugin specifically disables
it for its own options, then it is taking advantage of it.

And the converse, if you have a complex plugin with a number of options that
should not be autoloaded, then consider two options for your plugin: one
that contains options to be autoloaded, and one that does not. This is a
rare use case but is helpful.

On Mar 24, 2010, at 2:42 PM, Otto wrote:
> MySQL has search and replace capabilities which work very nicely,
> actually, and they can search and replace inside serialized data just
> as easily as they can in non-serialized data. You don't need a
> developer to adjust things.I'm not wading into this debate but am curious how MySQL can replace data back into the database for PHP serialized data?  Let's take, for example, the option for the Twenty Ten template (line break in the email are only for clarity):

	option_name: 
		mods_Twenty Ten

	option_value: 
		a:2:{s:12:"header_image";
			s:66:"http://example.com/wp-content/uploads/2010/03...";
			s:16:"background_image";
			s:70:"http://example.com/wp-content/uploads/2010/03...";}

Now if I run this in MySQL:

	UPDATE wp_options
	SET option_value = REPLACE(option_value,'/header.png','/new-header.png')
	WHERE option_name='mods_Twenty Ten'

...it will corrupt the data from PHP's unserialize perspective because the string lengths will no longer be correct. 

Is there some other way to update PHP Serialized arrays directly in MySQL that I do not know about?

-Mike

On Wed, Mar 24, 2010 at 2:34 PM, Mike Schinkel
 wrote:
> ...it will corrupt the data from PHP's unserialize perspective because the string lengths will no longer be correct.
>
> Is there some other way to update PHP Serialized arrays directly in MySQL that I do not know about?No, you just don't have to care about that. Unserializing an array
with a wrong string length generates a Notice error, but the
unserialize is still successful. And the maybe_unserialize() function
suppresses errors on the call to unserialize. So it'll still work and
the string size will get fixed the next time the option is updated.

-Otto

On Mar 24, 2010, at 3:43 PM, Otto wrote:
> On Wed, Mar 24, 2010 at 2:34 PM, Mike Schinkel
>  wrote:
>> ...it will corrupt the data from PHP's unserialize perspective because the string lengths will no longer be correct.
>> 
>> Is there some other way to update PHP Serialized arrays directly in MySQL that I do not know about?
> 
> No, you just don't have to care about that. Unserializing an array
> with a wrong string length generates a Notice error, but the
> unserialize is still successful. And the maybe_unserialize() function
> suppresses errors on the call to unserialize. So it'll still work and
> the string size will get fixed the next time the option is updated.Thanks for the clarification.

So does WordPress do maybe_unserialize() everywhere it unserializes to ensure the errors are suppressed?

My takeaway is that it's an acceptable hack at time while at other times it can result in data of actual data.  For example, if I wanted to change one but not all similar values in a complex option I could easily overwrite other data that I hadn't intended to overwrite.

So all options in one array, though having numerous benefits, are not a panacea and are not appropriate in all cases.

-Mike

On 3/24/10 1:42 PM, "Otto"  wrote:

> On Wed, Mar 24, 2010 at 12:56 PM, Potkanski, Jason
>  wrote:
>> Storing database variables in an array should be considered a bad practice.
>> Doing this is as an convenient  hack that shortens plugin design but has
>> significant consequences.
>
> Many people disagree with you on this. I'm one of those people.
>
> Serializing your options is not a "hack". It's the preferred method. Why?
> - Speed: Pulling one row out of the database is faster than pulling
> dozens of them
> - Simplicity: Having my options all together makes them easier to
> reference instead of having dozens of get_options calls.
> - Ease of design: Making settings pages which all use similar options
> is easier this way. No need for dozens of "register_setting" calls,
> dozens of slow get_options calls hitting the memory cache or the
> database, reduced numbers of SQL queries, etc.I'll sum this as this method gives plugin developers:
Fast Development Speed
Lower Network Traffic (via smaller DB call)
versus
More Memory Use (unneeded options potentially being loaded)
Increased Server CPU time (calls to serialize, deserialize and the preg_match to autodetect)
Database Denormalized. (RDBMS nightmare)>> Serialized data in the blog options table denormalizes the database.
>> ReCaptcha uses one blog option setting called reCaptcha. If I want to update
>> the keys across all my blogs in a wordpress MU install, I can not do it via
>> SQL alone, I have to write a php plugin to tinker with the values. (Yes, I
>> know reCaptcha has MU installation option and configuration file). Where I
>> could have help from a DBA to fix something, I now need a developer.
>
> MySQL has search and replace capabilities which work very nicely,
> actually, and they can search and replace inside serialized data just
> as easily as they can in non-serialized data. You don't need a
> developer to adjust things. Although it does strike me as rather
> trivial to write php code which basically says "include wp-load.php;
> $o = get_option('whatever'); $o['whatever'] = new value;
> update_option('whatever',$o);"I really want to see this MySQL easy regex search and replace inside serialized data. Easy and regex never go hand in hand.

You didn't address the database denormalization issue. That's a severe one. If plugin developers are not going to normalize their data, why use the blog options table at all? Use a flat file.>> Denormalization also means I couldn't have any systems integration or
>> monitoring on database values without custom plugins.
>
> They're stored as strings. What's so hard about monitoring strings?Lets say I want to write a Nagios monitor of a certain DB value of a plugin. In this case I want to monitor the roles of a blog (stored as serialized data) for security reasons. I couldn't just alter a Nagios standard function that can make a simple select call, I would have to write something to pull the data , deserialize it and make sure it is all correct.>> Other programming languages such as Java or Ruby don't have the same
>> serialization functions PHP does, so any other development work that may need
>> access to Wordpress data is restricted to PHP.
>
> Java has tons and tons of serialization stuff, actually. I suppose
> you've never seen "implements Serializable"?
>
> Admittedly, the syntax is not the same between the two, in which case
> you could either implement a parser (google will find one for you
> quickly), or you could switch the code to use a common interchange
> format. Probably the easiest way would be to use JSON. Or perhaps XML,
> if you swing that way.I've written stuff in java that implements serializable. You use this technique with Tomcat to make all server variables of an application stay persistent when the server is restarted. Or when you have multiple tomcat instances and want to share session data properly. You don't use it to dump java objects to the DB.

>>
>> Correct practice should be to avoid serialized arrays where possible and use
>> proper prefixing in blog options to avoid collisions with other plugins.
>
> I disagree. Correct practice would be to store your options in a
> single array as much as possible and to let WordPress handle the
> serialization for you as necessary. Only separate options out when you
> have a different load case for them (such as options you only need in
> specific places and not every time, large options, etc).I think we can have the best of both worlds. From the easy plugin design perspective, if you just throw an array at set_option or plugin option, it should be able to handle storing those options automatically. From my database normalization perspective, the set_option functions probably shouldn't use the serialize/deserialize methods if it can be avoided.

There are some further replies on this thread that will be interesting.

Too many posts to reply to. Concatenating responses. Trimming the fat.On Wed, Mar 24, 2010 at 2:53 PM, Potkanski, Jason
 wrote:
> More Memory Use (unneeded options potentially being loaded)Memory use is basically the same, or less. Like you said,
load_all_options loads them up anyway. Array storage is likely more
efficent.

> I really want to see this MySQL easy regex search and replace inside serialized data. Easy and regex never go hand in hand.

I never said anything about regex. If you're having to do regex, then
you're outside the scope of SQL statements to begin with, in which
case you'd have to write PHP regardless.

> You didn't address the database denormalization issue. That's a severe one. If plugin developers are not going to normalize their data, why use the blog options table at all? Use a flat file.

WordPress does not use "normalized" database design in any sense of
the term. IMO, normalization is a crutch for bad development practices
and an excuse to give DBA's too much power that they frankly should
never have been allowed to have in the first place.

> Lets say I want to write a Nagios monitor of a certain DB value of a plugin. In this case I want to monitor the roles of a blog (stored as serialized data) for security reasons. I couldn't just alter a Nagios standard function that can make a simple select call, I would have to write something to pull the data , deserialize it and make sure it is all correct.

Not necessarily. It depends on what you're trying to detect. For
something like that, all you really need to detect is when it changes.
Unless you are concerned about some specific content piece of the
value, of course. If you're wanting to monitor the roles as a whole,
then you're only concerned about changes to them in general instead of
a specific type of change.

> I've written stuff in java that implements serializable. You use this technique with Tomcat to make all server variables of an application stay persistent when the server is restarted. Or when you have multiple tomcat instances and want to share session data properly. You don't use it to dump java objects to the DB.

You're thinking too limited. Serializable can be used anytime you want
to turn a java object (with state information) into a streaming type
of output which can be restored to the object again. And yes, you most
certainly can use this technique to produce, say, a string which you
can store in a database and restore from the database again. I know of
several systems that do things like this.

> I think we can have the best of both worlds. From the easy plugin design perspective, if you just throw an array at set_option or plugin option, it should be able to handle storing those options automatically. From my database normalization perspective, the set_option functions probably shouldn't use the serialize/deserialize methods if it can be avoided.

If set_option and get_option didn't implement serialize automatically,
it would be necessary to do it yourself, to avoid putting multiple
options into the database. In other words, your "database
normalization" is the very thing that I consider undesirable in the
first place.

See, you seem to think that having 10 rows for 10 options is a good
thing. I say that if I always need all of those 10 options together,
then I should have them all together and in only 1 row of the
database. I don't need "1 option" at most places, I need all 10
options at most places.

Think about it, when do most plugins need options?
- At their settings screens, where they are displaying/changing those
options all at once.
- When they produce their output, which means that the options are
needed to produce said output. And usually, you need all of them to
produce that output. Or, if not all, then most of them. It's a very,
very rare case where I only need 1 or 2 of my plugin options in a
single page generation.On Wed, Mar 24, 2010 at 3:21 PM, Mike Schinkel
 wrote:
> So does WordPress do maybe_unserialize() everywhere it unserializes to ensure the errors are suppressed?Yes, get_option calls it.

> My takeaway is that it's an acceptable hack at time while at other times it can result in data of actual data.  For example, if I wanted to change one but not all similar values in a complex option I could easily overwrite other data that I hadn't intended to overwrite.

That would be a plugin programming error though, not a user error. And
it's one that is easy enough to avoid.

> So all options in one array, though having numerous benefits, are not a panacea and are not appropriate in all cases.

Not in all cases, no. Nothing is ever appropriate in "all" cases.

However, in *most* cases it's the best way to do it.On Wed, Mar 24, 2010 at 3:24 PM, Potkanski, Jason
 wrote:
> wp_load_options() bulk loads all these options with one DB call. Most of the time the get_option is going to hit the memory cache.Loading 10 rows of data takes more time than loading 1 row with the
same data. Seriously, it's a measurable amount.> Not sure if you need the separate table.
>
> I would propose the a new define "WP_NORMALIZE_DB" or some such which would use different version of the get/update/set_option functions that wouldn't serialize the data. It would probably require an addition to the schema options table of a 'child' column so that it relates to a master option.Negative. That would make plugin programming far more complex, as now
it would have to account for both cases and do it's own
(un)serialization when the user had enabled that. Very bad way to do
things.

-Otto

On Mar 24, 2010, at 4:58 PM, Otto wrote:
>> My takeaway is that it's an acceptable hack at time while at other times it can result in data of actual data.  For example, if I wanted to change one but not all similar values in a complex option I could easily overwrite other data that I hadn't intended to overwrite.
> 
> That would be a plugin programming error though, not a user error. And
> it's one that is easy enough to avoid.But one that would be very hard to test for robustness.  It's the edge cases in that data that would cause problems, enough so that I don't think I could recommend updating data in serialized arrays via SQL except in rare cares.  If the data is not in serialized arrays then it's easy to ensure robustness.

The key takeaway here is that, while there are many benefits to storing data, this is one downside for which there is no good solution when SQL is really the best option.  Saying it's "easy" just glosses over the real concerns.  

I'm not arguing that people don't store options in normalized data vs. serialized arrays, I'm saying we just shouldn't imply a recommendation that they use SQL to update serialized arrays by telling them it is easy. They shouldn't do that and if they really do need to then serialized arrays are not the answer. Sadly the person with the use-case where it's not the answer isn't always the same person who decides how to store the option.)

-Mike

On 3/24/10 3:58 PM, "Otto"  wrote:


>> You didn't address the database denormalization issue. That's a severe one.
>> If plugin developers are not going to normalize their data, why use the blog
>> options table at all? Use a flat file.
>
> WordPress does not use "normalized" database design in any sense of
> the term. IMO, normalization is a crutch for bad development practices
> and an excuse to give DBA's too much power that they frankly should
> never have been allowed to have in the first place.DBAs on power trips are common for various other reasons. I have never seen anyone argue that normalization is a crutch or bad thing. You can skip it for performance reasons when justified - that should be very rare.>> Not sure if you need the separate table.
>>
>> I would propose the a new define "WP_NORMALIZE_DB" or some such which would
>> use different version of the get/update/set_option functions that wouldn't
>> serialize the data. It would probably require an addition to the schema
>> options table of a 'child' column so that it relates to a master option.
>
> Negative. That would make plugin programming far more complex, as now
> it would have to account for both cases and do it's own
> (un)serialization when the user had enabled that. Very bad way to do
> things.Set/get/update/wp_load_options/wp_options could be rewritten to not use serialization and provide a one stop point for disassembly and reassembly of an array of options from the db and back without relying on the plugin to do it. Probably two additional columns to the options table.

On Wed, Mar 24, 2010 at 4:43 PM, Potkanski, Jason
 wrote:
> You can skip it for performance reasons when justified - that should be very rare.I disagree and think that it's far more common than you think. JOINs
are bloody costly, and if your DB is truly normalized, then it often
takes far, far too many of those. And again, pulling 1 row is faster
than pulling 10, even if you only use one SELECT statement to do it.

> Set/get/update/wp_load_options/wp_options could be rewritten to not use serialization and provide a one stop point for disassembly and reassembly of an array of options from the db and back without relying on the plugin to do it. Probably two additional columns to the options table.

So for the case of set_option, having it split the array into pieces
and then execute a dozen SQL INSERT statements to an external database
server is somehow faster than simply running a built-in, compiled,
function across the data? Your logic escapes me here.

Your solution is slower, in all cases. And the "advantage" of having
separated options is basically non-existent for anybody who isn't
accessing the database directly (outside of the WordPress
environment). It just doesn't make any sense to do it that way, as far
as I can tell.

-Otto

On Wed, 24 Mar 2010 12:56:42 -0500
"Potkanski, Jason"  wrote:

> Storing database variables in an array should be considered a bad
> practice. Doing this is as an convenient  hack that shortens plugin
> design but has significant consequences.
> 
> Serialized data in the blog options table denormalizes the database.
> ReCaptcha uses one blog option setting called reCaptcha. If I want to
> update the keys across all my blogs in a wordpress MU install, I can
> not do it via SQL alone, I have to write a php plugin to tinker with
> the values. (Yes, I know reCaptcha has MU installation option and
> configuration file). Where I could have help from a DBA to fix
> something, I now need a developer.
> 
> Denormalization also means I couldn't have any systems integration or
> monitoring on database values without custom plugins. Other
> programming languages such as Java or Ruby don't have the same
> serialization functions PHP does, so any other development work that
> may need access to Wordpress data is restricted to PHP.
> 
> There are autoload features of blog options tables which many plugins
> are not taking advantage of.
> 
> There may also be performance penalties to serializing and
> deserializing arrays all the time that cause performance problems on
> high traffic sites.
> 
> Correct practice should be to avoid serialized arrays where possible
> and use proper prefixing in blog options to avoid collisions with
> other plugins.
> 
> --
> 
> Jason Potkanski
> Tribune Technology
>I understand what you are saying, so what is your solution to this
problem?

Storing every option separately in the WordPress options table creates
an overhead on MySQL calls. Reading the database 10 times for 10
options would be a lot slower as calling the database 1 times and
unserializing the option.

Currently under WordPress you either have to read the database 10 times
for 10 different options or serialize the data and use 1 database call.
I think the 1 call would be quicker.

I can think of a solution that would take out the serialization but it means rewriting the
get/update/set_option functions and adding a table.

On 3/24/10 2:28 PM, "Peter van der Does"  wrote:On Wed, 24 Mar 2010 12:56:42 -0500
"Potkanski, Jason"  wrote:
>
>>
>> Correct practice should be to avoid serialized arrays where possible
>> and use proper prefixing in blog options to avoid collisions with
>> other plugins.
>>
>
> Ils understand what you are saying, so what is your solution to this
> problem?

> Storing every option separately in the WordPress options table creates
> an overhead on MySQL calls. Reading the database 10 times for 10
> options would be a lot slower as calling the database 1 times and
> unserializing the option.wp_load_options() bulk loads all these options with one DB call. Most of the time the get_option is going to hit the memory cache.> I can think of a solution that would take out the serialization but it means
> rewriting the
> get/update/set_option functions and adding a table.Not sure if you need the separate table.

I would propose the a new define "WP_NORMALIZE_DB" or some such which would use different version of the get/update/set_option functions that wouldn't serialize the data. It would probably require an addition to the schema options table of a 'child' column so that it relates to a master option.