The `_network_option()` parameter order will be changing to accept `$network_id` first. The `_site_option()` functions will remain in use throughout core as our way of retrieving a network option for the current network.
See #28290.
git-svn-id: https://develop.svn.wordpress.org/trunk@34912 602fd350-edb4-49c9-b593-d223f7449a82
The `WP_INSTALLING` constant is a flag that WordPress sets in a number of
places, telling the system that options should be fetched directly from the
database instead of from the cache, that WP should not ping wordpress.org for
updates, that the normal "not installed" checks should be bypassed, and so on.
A constant is generally necessary for this purpose, because the flag is
typically set before the WP bootstrap, meaning that WP functions are not yet
available. However, it is possible - notably, during `wpmu_create_blog()` -
for the "installing" flag to be set after WP has already loaded. In these
cases, `WP_INSTALLING` would be set for the remainder of the process, since
there's no way to change a constant once it's defined. This, in turn, polluted
later function calls that ought to have been outside the scope of site
creation, particularly the non-caching of option data. The problem was
particularly evident in the case of the automated tests, where `WP_INSTALLING`
was set the first time a site was created, and remained set for the rest of the
suite.
The new `wp_installing()` function allows developers to fetch the current
installation status (when called without any arguments) or to set the
installation status (when called with a boolean `true` or `false`). Use of
the `WP_INSTALLING` constant is still supported; `wp_installing()` will default
to `true` if the constant is defined during the bootstrap.
Props boonebgorges, jeremyfelt.
See #31130.
git-svn-id: https://develop.svn.wordpress.org/trunk@34828 602fd350-edb4-49c9-b593-d223f7449a82
Replaces all uses of `*_site_option()` with the corresponding "network" function.
This excludes one usage in `wp-admin/admin-footer.php` that needs more investigation.
Props spacedmonkey.
See #28290.
git-svn-id: https://develop.svn.wordpress.org/trunk@34778 602fd350-edb4-49c9-b593-d223f7449a82
Introduces `add_network_option()`, `update_network_option()`, `get_network_option()`, and `delete_network_option()`, which use the internals previously found in the `*_site_option()` functions and allow for a network ID to enable cross network storage and retrieval of network options.
* `*_site_option()` functions are now wrappers for `*_network_option()` and will interact with options for the current network in a multisite environment.
* All will continue to fallback to `*_option()` for non-multisite uses.
* Adds basic tests for cross network storage and retrieval.
* Existing tests for `*_site_option()` functions provide coverage for storage and retrieval of current network options.
Props spacedmonkey, DrewAPicture, jeremyfelt.
See #28290.
git-svn-id: https://develop.svn.wordpress.org/trunk@34777 602fd350-edb4-49c9-b593-d223f7449a82
This todo has been in place since the original merge of MU. At the time of merge, `wpmu_protect_special_option()` protected an empty array, and there has been no noticeable need since. As we introduce `_network_option()`, let's leave this behind. A new ticket can be opened if necessary.
See #28290.
git-svn-id: https://develop.svn.wordpress.org/trunk@34756 602fd350-edb4-49c9-b593-d223f7449a82
Add unit tests - there were none. Mock `set_user_setting()` since it won't run due to `headers_sent()` being `true`.
Fixes#22781.
git-svn-id: https://develop.svn.wordpress.org/trunk@33840 602fd350-edb4-49c9-b593-d223f7449a82
[31628] made it possible to pass an `$autoload` param to `update_option()` that
applies when the option does not yet exist in the database. The current
changeset introduces parity for existing options: the `$autoload` setting
for existing options can be changed via the `$autoload` parameter. For internal
simplicity, `$autoload` is ignored for existing options when `$value` is not
also changed.
This changeset also moves `update_option()` tests into their own class.
Props dd32.
Fixes#26394.
git-svn-id: https://develop.svn.wordpress.org/trunk@31640 602fd350-edb4-49c9-b593-d223f7449a82
When creating an option via `add_option()`, the `$autoload` param allows you to
tell WP whether the option should be loaded as part of the 'alloptions' cache
during every pageload. `update_option()`, when used with a non-existent option
calls `add_option()` internally. The new `$autoload` param in `update_option()`
is passed along to `add_option()` in cases where the option does not yet exist.
The associated unit tests are skipped on multisite due to an issue that causes
`WP_INSTALLING` to force cache misses. See #31130.
Props codix, nofearinc, MikeHansenMe.
Fixes#26394.
git-svn-id: https://develop.svn.wordpress.org/trunk@31628 602fd350-edb4-49c9-b593-d223f7449a82
`add_option()` and `update_option()` both call `get_option()` to compare the
value passed to the function with any existing value for the given option name.
When a `'default_option_'` filter is in place to change the default value of
an option, `add_option()` and `update_option()` ought to check against the
filtered value, rather than a hardcoded `false`, in order to determine whether
a prior value exists.
Props GregLone, tyxla.
Fixes#31047.
git-svn-id: https://develop.svn.wordpress.org/trunk@31473 602fd350-edb4-49c9-b593-d223f7449a82
Per our inline documentation standards, no further use of the `@uses` tag is recommended as used and used-by relationships can be derived through other means. This removes most uses of the tag in core documentation, with remaining tags to be converted to `@global` or `@see` as they apply.
Fixes#30191.
git-svn-id: https://develop.svn.wordpress.org/trunk@30105 602fd350-edb4-49c9-b593-d223f7449a82
