WordPress plugin: options & storage

Where to put the data the plugin owns. WordPress offers several storage primitives — wp_options, four flavors of *_meta, transients, multisite site options/transients, and custom tables — and picking the right one is the single highest-leverage architectural decision for a plugin's long-term performance and maintainability.

This skill covers picking + using them correctly. It does NOT cover one-time activation seeding (see wp-plugin-lifecycle) or REST endpoint validation of stored values (see wp-rest-api).

Multisite caveat (read first)

This skill's author works on single-site WordPress; the multisite advice below is derived from WP source code but has not been end-to-end tested in a multisite environment. The primitives — get_site_option / update_site_option / set_site_transient / delete_site_option — exist and are documented; their semantics here are taken from wp-includes/option.php. If you ship a plugin that has actual multisite users, run an integration test on a real network install before relying on these patterns. Some quirks (switch_to_blog interactions, network admin context detection, blog-id-aware caches) only surface in a real network.

When to use this skill

Trigger when ANY of the following is true:

• Scaffolding a new plugin's settings page or any persistent state.
• Reviewing a plugin where you see hundreds of update_option calls — performance smell.
• Picking where to store a piece of data: option vs meta vs transient vs custom table.
• Investigating a slow autoload payload (SELECT option_name, option_value FROM wp_options WHERE autoload IN (...)).
• The user asks "should I JSON this and put it in an option" — short answer below, see "JSON storage trap".