As an example, let's update the color of your new plugin setting from red to blue.
<?php update_option( 'pdev_plugin_color', 'blue' ); ?>
The update_option()function accepts the following parameters:
option: Name of the option to update
value: Value of the option you are updating
autoload: Whether to load the option when WordPress starts
The difference between add_option() and update_option() is that the first function does nothing if the option name already exists, whereas update_option() checks if the option already exists before updating its value and creates it if needed.
Retrieving Options
To fetch an option value from the database, use the function get_option().
<?php $pdev_plugin_color = get_option( 'pdev_plugin_color' ); ?>
The first thing to know about get_option() is that if the option does not exist, it will return false. The second thing is that if you store Booleans, you might get integers in return.
The get_option()function accepts the following parameters:
option: Name of the option to retrieve
default: Value to return if the option does not exist. The default return value is false.
As an illustration of this behavior, consider the following code block that creates a couple of new options with various variable types:
<?php update_option( 'pdev_bool_true', true ); update_option( 'pdev_bool_false', false ); ?>
You can now retrieve these options, along with another one that does not exist, and see what variable types are returned, shown as an inline comment below each get_option() call:
<?php var_dump( get_option( 'nonexistent_option' ) ); // bool(false) var_dump( get_option( 'pdev_bool_true' ) ); // string(1) "1" var_dump( get_option( 'pdev_bool_false' ) ); // bool(false) ?>
To avoid an error when checking option values, you should store true and false as 1 and 0. This means also that you need to strictly compare the return of get_option() with Boolean false to check if the option exists.
<?php //set the option as true update_option( 'pdev_plugin_enabled', 1 ); if( get_option( 'pdev_plugin_enabled' ) == false ) { // option has not been defined yet // ... echo 'NOT DEFINED YET'; } else { // option exists // ... echo 'OPTION EXISTS!'; } ?>
You can also specify what value you want to be returned if the option is not found in the database, with a second option parameter to get_option(), like in the following example:
<?php $option = get_option( 'pdev_plugin_option', 'Option not found' ); ?>
Loading an Array of Options
You have seen that saving multiple options in a single array is best practice. A complete example of saving and then getting values from one array would be as follows:
<?php // To store all of them in a single function call: $options = array( 'color' => 'red', 'fontsize' => '120%', 'border' => '2px solid red' ); update_option( 'pdev_plugin_options', $options ); // Now to fetch individual values from one single call: $options = get_option( 'pdev_plugin_options' ); // Store individual option values in variables $color = $options[ 'color' ]; $fontsize = $options[ 'fontsize' ]; $border = $options[ 'border' ]; ?>
Saving and retrieving options enclosed in an array has another advantage: variable Boolean types within the array are preserved. Consider the following example:
<?php add_option( 'pdev_test_bool', array( 'booltrue' => true, 'boolfalse' => false ) ); ?>
Now get the option value from the database with var_dump( get_option( 'test_bool' ) ). See how Boolean types are retained, contrary to the previous example:
// output result var_dump( get_option( 'pdev_test_bool' ) ); array(2) { ["booltrue"] => bool(true) ["boolfalse"]=> bool(false) }
Deleting Options
Now that you understand how to create, update, and retrieve options, let's look at deleting an option. Deleting an option needs a self‐explanatory function call.
<?php delete_option( 'pdev_plugin_options' ); ?>
This function call returns false if the option to delete cannot be found and returns true otherwise. You will mostly delete options when writing uninstall functions or files (see Chapter 2).
The Autoload Parameter
By default, all the options stored in the database are fetched by a single SQL query when WordPress initializes and then caches. This applies to internal WordPress core settings and options created and stored by plugins.
This is efficient behavior: no matter how many get_option() calls you issue in your plugins, they won't generate extra SQL queries and slow down the whole site. Still, the potential drawback of this autoload technique is that rarely used options are always loaded in memory, even when not needed. For instance, there is no point in fetching backend options when a reader accesses a blog post.
To address this issue when saving an option for the first time, you can specify its autoload behavior, as in the following example:
<?php add_option( 'pdev_plugin_option', $value, '', $autoload ); ?>
Note the empty third parameter: This is a parameter that was deprecated several WordPress versions ago and is not needed any more. Any value passed to it will do; just be sure not to omit it.
The fourth parameter is what matters here. If $autoload is anything but 'no' (or simply not specified), option pdev_plugin_option will be read when WordPress starts, and subsequent get_option() function calls will not issue any supplemental SQL query. Setting $autoload to 'no' can invert this: this option will not be fetched during startup of WordPress, saving memory and execution time, but it will trigger an extra SQL query the first time your code fetches its value.
NOTE If you want to specify the autoload parameter, you need to use add_option() instead of update_option() when creating an option the first time. If you don't need this parameter, always using update_option() to both create and update will make your code more simple and consistent.
Of course, specifying the autoload parameter upon creation of an option does not change the way you fetch, update, or delete its value.
Segregating Plugin Options
