WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In the book 'Professional WordPress Development' I found this tip:

As a rule of thumb, if your options are needed by the public part of the blog, save them with autoload. If they are only needed in the admin area, save them without autoload.

Wouldn't that result in many extra SQL queries in the backend if all plugin developers followed that advice, thus slowing down the admin side?

What would be a good example of using autoload with plugin options?

share|improve this question
up vote 5 down vote accepted

Quite personally I disagree with the author of the book to an extent. If you are auto-loading multiple options in your database when Wordpress is initialising it's doing a lookup that looks like this: *"SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes'"* — at the beginning. Now, imagine if you had 40 options, that's 40 separate DB queries.

However if you are only auto-loading a serialised array of options, that's potentially hundreds of options within the option option stored as a serialised string. So it's not entirely bad to auto-load only in the instance where you're auto-loading more than one option at a time.

I have seen plugins abuse the options API badly by having multiple options separately stored, it's unnecessary overhead. So remember, always serialise unless there's a good reason you don't want too.

The benefit of autoloading is that the options are cached. So when Wordpress is initialised, the options are cached and hence more efficient. But like I said, if you have 80 separate options there will be an initial performance hit until they're cached which is bad.

Here is an example of serialising multiple options into the one:

$myoptions = array(
    'option1' => 'option value',
    'option2' => 'option value 2',
    'option3' => 'option value 3'

update_option('theme_settings_field', $myoptions );

$options = get_option('theme_settings_field');

if ($options) {
    $option1 = $options['option1'];

As you can see in the example, you can serialise an array which from a database perspective is one option comprised of many options. When you retrieve the options, they're unserialised into an array you can access (like the example shows above).

share|improve this answer
The author does emphasise that it's better to serialise options in an array. The point in the quote I pasted is more about autoloading or not autoloading options, whether they are stored in an array or not. And hence my question is about that rather than about storing options in an array or not. – drtanz Feb 21 '13 at 3:50
Well to put it bluntly, no it doesn't add any unnecessary overheard if you're auto-loading a serialised option array. In-fact it's the preferred option because it'll cache your array of settings when you go to use get_option instead of doing a DB lookup. If you don't autoload, the first time you use get_option it is going to do a database query anyway. – Dwayne Charrington Feb 21 '13 at 6:15
Right, so in that case you wouldn't be agreeing that disabling autoloading for admin-side options is a good rule of thumb. – drtanz Feb 21 '13 at 7:49
That's correct. I wouldn't disable auto-loading admin options (nor front-end options). There is a benefit in my opinion to auto-load. – Dwayne Charrington Feb 21 '13 at 23:33

By default options are auto-loaded and you need to do some effort to prevent that. If you create an option by using the update_option API it is created as auto-loading. To have a non auto-loading option you have to create it by calling add_option with the fourth parameter set to "no". Due to the difference in the ease of API use I am guessing most options are autoloaded.

Before going that route you should also consider this ticket in which it is claimed that wordpress.com just autoloads all options.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.