All WordPress options as single option (serialized multidimentional array), or multiple options?

I know my way around WordPress, but right now I'm developing a rather big and advanced WordPress plugin.

For this reason I've put a lot of thought into my data structure.

When I was a beginner I always used to save it like this(get_option(prefix_option_name)). Then I started using multidimentional arrays, registering 1 for each settings_section and now I typically save all plugin options in 1 big multidimentional array like this: plugin_options[section][option][evt.more subs here][etc]

This does work fine, and I do like the fact that I can just pull all options out one time in the init-hook ($plugin_options = get_option('plugin_options), so I can work with the $options "locally" in the plugin, HOWEVER...

Taking into account that WordPress is already utilizing transients to cache (WP Cache API) the get_option call, which is better for performance? Even though my plugin has a lot of options, I guess you could never reach the limit of the longtext type (4gb data or something), even I packed it all in one single serializable multidimentional array? But I want to do what's best from a performance point of view, so in short, here's my question again:

What is best (for a rather big and complex wordpress plugin)?

  1. Saving all your plugin options as a single option (serialized multidimentional array), like eg. name='plugin_options[section][option]'
  2. Splitting each options tab and options page into it's own options entry like eg: section[option][etc]
  3. simply just prefixing all your plugin options and putting then as a seperate db entry like eg. pluginname_option_1, pluginname_option_2

I like the "single plugin option" approach, but right now I'm confused as to whether or not fetching/updating 1 big array from the db really is the best way to go, if the array get's REALLY big - like in a very big and advanced plugin.

The problem with 3 as I see it is that with 1, you would only need to fetch all options in one db-call, where in 3 (where you save each option as a db entry for itself), you would have to query the db for each specific and individual option.

But which is better 1 call for all options, 1 for each section or 1 for each individual option (I guess my question could be narrowed down to this in the end :D). Can the serializable "single option" plugin option multi-dimentional array realistically grow too big? Should it be split up?

Look forward to hearing your opinions on this. Cheers. :-)

Answers


Personally, I usually go for the single option.

If you're using multiple options in a single page load, then each of those would be one db call (unless they're autoloaded). If you're using all or most of your options in a page anyway, then you would be saving a db call for each option you're using if you put them all in a single option. The savings here can stack up quick.

However, this still depends on how much data you're putting in your single option though. If it's quite large then unserializing or serializing your data might have a performance impact on your server. (see: serialize a large array in PHP?). You will have to do some sort of benchmark to measure which is faster if you're handling lots of data.


FWIW, WordPress already autoloads and caches all options on each page load (unless an option is saved as not to do so), so it doesn't really matter.


This isn't strictly related to performance, but one downside of using a single option is that, if you register it with register_setting(), you lose the ability to take advantage of the sanitize_callback param.

You'd still want to register one, but it'd have to be your own custom function that loops through the array and manually calls things like absint(), sanitize_text_field(), etc.

If you have individual options, you just register the sanitize_callback as absint (or whatever), and you're done.


Need Your Help

php paging class

php symfony1 pagination propel

Can anyone recommend a good PHP paging class?