All WordPress options as single option (serialized multidimentional array), or multiple options?
arrays, caching, php, plugins, wordpress
Solution
I tend to prefer separate options for unrelated data. It most cases it doesn't matter for performance, but there significant benefits compared to combining them.
Performance
If the option is autoloaded -- which they are by default -- then using separate options won't result in any extra database queries.
If you're using Memcache, then by default objects are limited to 1mb, and if your option grows beyond that, it will bypass caching and hit the database every time.
Other Considerations
I think Core has been designed with the assumption that options will be separated, so if you combine them then you have to do extra work to utilize some of the helpful things that Core otherwise gives you for free.
For example, all of these common practices are easy to do with individual options, but require extra logic to reduce the combined option to the targeted entry:
- `pre_update_option{$option_name}`
- Sanitization callbacks with `register_setting`
- Retrieving settings from the REST API
It can also be an "all your eggs in one basket" problem; if a bug or some other factor causes unexpected data loss, the user can lose everything, instead of just a single datum. That's rare in practice, but I've seen it happen, with very damaging effects. People should have backups, but many don't, and I've also seen backups fail in practice.
Problem
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)? - Saving all your plugin options as a single option (serialized multidimentional array), like eg. name='plugin_options[section][option]' - Splitting each options tab and options page into it's own options entry like eg: section[option][etc] - 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. :-)