This is a question about performance. I've used the Wordpress Settings API in order to register fields and for a plugin that has 30+ fields that can cause a huge amounts of lines of code, in addition, sometimes the plugin has to use get_option() a few times to know if it can show specific data on a specific admin page, this causes more database calls.

Instead, wouldn't it be better to save all options in JSON format in 1 field in the options table? Once the admin page loads you just use get_option('prefix_my_settings') which will then retrieve a json of all the plugin settings? Then all of the plugin settings are stored in 1 location and uses only 1 database request for each page load.

What are the downsides for using such method and is there a character limit for an option field?

This is a question about performance. I've used the Wordpress Settings API in order to register fields and for a plugin that has 30+ fields that can cause a huge amounts of lines of code, in addition, sometimes the plugin has to use get_option() a few times to know if it can show specific data on a specific admin page, this causes more database calls.

Instead, wouldn't it be better to save all options in JSON format in 1 field in the options table? Once the admin page loads you just use get_option('prefix_my_settings') which will then retrieve a json of all the plugin settings? Then all of the plugin settings are stored in 1 location and uses only 1 database request for each page load.

What are the downsides for using such method and is there a character limit for an option field?

• settings-api

• 1 if each get_option call does a separate database query then this sounds like you've turned off autoload on your option ( or this is an assumption that hasn't been checked and you're unaware of the autoload parameter ). Is there a particular concern here? A query to load an option is very cheap and if you're seeing major performance differences by doing this then that's alarming and implies some very strange and unusual behaviour. This sounds like micro-optimising – Tom J Nowell ♦ Commented Jan 28, 2022 at 18:20
• Hey @TomJNowell - I was unsure of how I should use that variable. Here's a quote from Kinsta's article Data is being autoloaded by a plugin when really it should be set to “no.” A good example of this would be a contact form plugin. Does it need to load data on every page or just the contact page?. What would be considered a large amount of autoloaded fields? What would be a good practice when setting autoload value for fields? If I set all fields to autoload false, that means that get_option will be slower? Also, I'm just trying to figure out best practices :-) Thanks for the input! – odedta Commented Jan 28, 2022 at 19:50
• when you say slower, have a think about how much slower that is. For example, if I'm making large amounts of cups of tea for people I could ask you if using sugar cubes with rounded corners will be faster or slower, but any sane person would realise the difference between the two is of no practical use. Unless you can demonstrate that this is causing observable noticeable load using actual measurements then this question is not going to be useful to you and is a red herring – Tom J Nowell ♦ Commented Jan 28, 2022 at 20:07
• 2 Rounded corners make sugar cubes more aerodynamic when dropping in the tea. – vancoder Commented Jan 28, 2022 at 22:21
• Alright @TomJNowell, thanks for bringing things into context. Much appreciated! – odedta Commented Jan 29, 2022 at 9:42

1 Answer 1

There's always a character limit, but option_value is LONGTEXT so unless you anticipate more than 4GB of data you should be fine.

I'd suggest json is unnecessary - you can save a PHP array as the value and it will be serialized/deserialized automatically.

That said, as Tom points out, this is really micro-optimising, and won't really impact performance either way in the real world. If you want to keep your settings together for organizational/clarity reasons though, go ahead.