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:
You can see all of your site’s current options on your dashboard using following path:
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:
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)
You can use functions like
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.
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.
update_option() will default to
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:
- Identify which options are the largest.
- Backup and audit the problematic options.
- Delete or set the option to
- Figure out the root cause for why the option got to its problematic size.
- 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
WP-CLI and the VIP-CLI
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 output similar to this example:
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
vip @wpvip.production -- wp option get rewrite_rules --format=json 2>&1 | tee rewrite_rules.json
The JSON output will also contain some confirmation text about running the command on your site. If you intend to use this data later make sure you remove that from the 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
If successful, the returned output will look similar to this example:
=================================== + 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 use the WP-CLI command:
wp option delete <option_name>
Be careful how often you change data in
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
Only store the bare minimum amount of data in
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
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.