Working with wp_options

WordPress has a built-in way to store simple key-value data known as the Options API.  This API is can be used to store data like a theme setting, a plugin setting, or even global site settings (e.g. Number of Posts to show on the homepage: 3). This data is stored in the wp_options table and has 2 unique keys: option_id and option_name.

Working with options

When adding an option to your wp_options table, there are a few things you should consider that will impact your site’s performance:

Large options

If you want to store options that are large in size, please consider using WP Large Options.  This plugin will store options in a custom post type and prevent the wp_options table from getting too large.

Data that might be a good fit for using WP Large Options:

• Large HTML fragments
• Any CSS (though we recommend storing this in theme files instead)

Autoloading

You can use functions like add_option() and update_option() to create options in the wp_options table. Here’s an example of what the table might look like:

You’ll notice that the fourth column is titled autoload.  Whenever a request comes to WordPress, it has to make many complicated and quick decisions in order to serve the right information to a user. One well-known way to improve the speed at which this can be done is to define certain options as needed on every page load and others as not really that important.  The way you do this is by setting an option to autoload = yes.  When you do that, WordPress will store all of those options into a single object and load them on every page load.  On VIP Go, we optimize this by loading these options into Memcached to improve the speed at which WordPress can load and use these options.

One very important note is that our Memcached implementation has a limit of 1 MB per object.  That means that the size of the AllOptions cache object cannot exceed 1 MB (code reference). We do this intentionally because we know the severe performance impact that loading too much data in AllOptions can have. Our approach, instead, is to set a hard limit and to educate and help you understand how to best use this part of WordPress.

Identify and resolve problems with AllOptions

The most common problem with AllOptions happens when its size reaches 1 MB. Letting your site’s option reach that size will have negative performance implications and can lead to the site being unavailable until the problem is fixed.

If you have an issue with your AllOptions size, we recommend the following steps:

1. Identify which options are the largest.
2. Backup and audit the problematic options.
3. Delete or set the option to autoload=no.
4. Figure out the root cause for why the option got to its problematic size.
5. Fix the root problem to ensure site performance is not impacted further.

Here are some tools and suggestions to help you with diagnosing and fixing a problem with AllOptions:

WP-CLI and the VIP-CLI

Two tools available for use are WP-CLI, a command-line interface for WordPress, and VIP-CLI, a tool to interact with your VIP applications through the command line.

Using the VIP-CLI to identify big options

With the VIP-CLI, we have a command available that will show you in a table format which options inside AllOptions are taking up the most space:

vip @<app-alias>.<app-environment> -- wp vip alloptions find --big

Running that command will return the following:

$ vip @wpvip.production -- wp vip alloptions find --big
Success: Big options for https://wpvip.com - Blog ID 1:
+---------------------------------+--------+
| name                            | size   |
+---------------------------------+--------+
| large                           | 512000 |
| rewrite_rules                   | 22387  |
| wp_user_roles                   | 7967   |
| jetpack_available_modules       | 1211   |
| jetpack_constants_sync_checksum | 1183   |
| subscription_options            | 529    |
+---------------------------------+--------+
Total size of all option values for this blog: 541 KB
Size of serialized alloptions for this blog: 555 KB
		use `wp option get <option_name>` to view a big option
		use `wp option delete <option_name>` to delete a big option
		use `wp option autoload set <option_name>` no to disable autoload for option

Saving a backup of your options

You can save the output from a specific option using WP_CLI.  Here’s an example of how to save the output from rewrite_rules:

vip @wpvip.production -- wp option get rewrite_rules --format=json 2>&1 | tee rewrite_rules.json

Disabling autoload for an option

To disable an option from autoloading, you can use vip @<app-alias>.production -- wp option autoload set <option_name> no to remove that option from AllOptions. Remember to make sure that this is also fixed where the option originally was added or updated.

Clearing the AllOptions cache

When you’ve made changes to AllOptions you might still need to clear the Object Cache to make sure your data is now what’s being stored in the cache.   You can do that by running the wp cache delete <cache key> <cache group> WP_CLI command:

vip @wpvip.production -- wp cache delete alloptions options
===================================
+ command: wp cache delete alloptions options
===================================
✔ Are you sure you want to run this command on PRODUCTION for site wpvip.com? (y/N) · true
Success: Object deleted.

Deleting an option

To delete an option you can use the WP CLI command:  wp option delete <option_name>

Other considerations

Be careful how often you change data in AllOptions

Since AllOptions is stored in Memcached, when the data changes, WordPress will have to rebuild the cache for that key which could impact your site’s performance.  If you need some data stored for quick retrieval, you can just store it in the Object Cache without having to use AllOptions.

Only store the bare minimum amount of data in wp_options

Instead of storing the whole HTML fragment, just store a Post ID for what you need and let your theme do the rest.

Widgets are stored in wp_options

Widgets are stored in wp_options, so be careful to not store too much data in those HTML or Text Widgets.  Instead, use a custom post type for that kind of data.