Hot answers tagged add-options
Yes, sort of. When the get_option call is made, WordPress runs a function called wp_load_alloptions, which either grabs a cached copy of all autoloaded options or loads all those options into the cache. Then wp_load_alloptions returns an array of all the autoloaded options. If your option is autoloaded (specified when you use the add_option function), it ...
I would do this when you call add_options_page(), not later. It's always better to do this with the supported API instead of playing with the internal structures. The plugin updater periodically checks the plugin status and then saves the result in a transient. This means that it only reads this cached status when the menu is created, it doesn't do the full ...
No, only the options that are specifically loaded with autoload set to true See http://codex.wordpress.org/Function_Reference/add_option So if it is an option that is needed on every page, when you add it to the db, set autoload=true. After that, just use get_option normally - wp will handle the cacheing etc.
Custom fields should be used to store additional details assigned to posts/pages. You should use Options API to store global options. You should use user meta to store additional user details. You can also read this: Best way to present options for home page in admin?
You are talking about "Options". These are saved in the *_options table and can be stored and retrieved using a number of Core functions (straight from the Codex page above): Add/Delete Option add_option() delete_option() add_site_option() delete_site_option() Get/Update Option get_option() update_option() get_site_option() ...
You can use get_site_option() function to get single network-wide option. Example : $singleoption = get_site_option( 'siteurl' ); If you want to get all options from all sites use wp_load_alloptions() function. Example : $alloptions = wp_load_alloptions()
Only top voted, non community-wiki answers of a minimum length are eligible