WordPress options in Standalone vs Multisite ( aka update_option vs update_site_option )

While researching how data needed to be migrated for Multisite functionality in BackupBuddy I’ve had to do a lot of digging into the differences between how options (and other) data is stored and retrieved in Standalone versus Multisite WordPress setups. This was an extremely confusing venture and not intuitive at all. I’ll start with a table of my resulting findings and explain from there. In this example I’m using update_option() and update_site_option(). The same structure is followed for transients and other data as well so this basis should work for you. It is important to note that when in a Multisite environment the terms site and blog are used interchangeably by WordPress core in code and mean the same or entirely different things depending on context. This is an unfortunate failure of WordPress and adds to the confusion.

  update_option update_site_option [global]
Standalone Site wp_options [local (effectively global)] wp_options [global]
Multisite Main Site or Network Admin wp_options [local] wp_sitemeta, site_id (aka network id) set [global]
Multisite Site (non-main site) wp_##_options [local] wp_sitemeta, site_id (aka network id) set [global]

In a Standalone WordPress installation update_option() stores data in the wp_options database table. The update_site_option() function falls back to update_option() when in standalone mode so there is really not much of a functional difference here. This data can be updated / retrieved anywhere in the WordPress installation so it’s effectively global. It’s best to use the proper one though in case the site is ever migrated into a network with BackupBuddy.

In a Multisite WordPress installation things get … weird and non-intuitive. The verbage used by WordPress is very confusing unfortunately. (Individual sites in a Network installation are called Sites — but in code they are often called blogs and you can have multiple blogs within a site (you can technically have multiple blogs within multiple sites within one Network but that’s another story…). Things vary depending on where you are so keep your eye out for this. If you are in the main site dashboard, main site front-end, or Network admin, update_option() will place data in wp_options. Data manipulated while in the Network Admin behaves as if it was manipulated within the Main Site (!). If you are in another of the Network’s site admin/dashboard that is not the main site and not the Network Admin then update_option() stores data in wp_##_options where ## is the ID number of the blog. These options are only available within the respective area. These are `local options`. If at any time you want to set an option that is globally accessible by its name anywhere in the entire network use update_site_option().

2 thoughts on “WordPress options in Standalone vs Multisite ( aka update_option vs update_site_option )”

  1. It seems like these inconsistencies exist all over WP. It’s enough for me to think twice about using it.

    Anyway, thanks for the info. Helped me in a jam.

Leave a Reply

Your email address will not be published. Required fields are marked *