WordPress' code just... wasn't.
This is now dealt with.
Props jrf, pento, netweb, GaryJ, jdgrimes, westonruter, Greg Sherwood from PHPCS, and everyone who's ever contributed to WPCS and PHPCS.
Fixes#41057.
git-svn-id: https://develop.svn.wordpress.org/trunk@42343 602fd350-edb4-49c9-b593-d223f7449a82
Previously an option containing an object would trigger an SQL `UPDATE` on all calls to `update_option`, even if the old and new values were identical. This was due to the old and new values having differing resource IDs.
This change compares the old and new values as serialized data to remove the resource ID from the comparison.
Props salcode, bradyvercher, peterwilsoncc.
Fixes#38903.
git-svn-id: https://develop.svn.wordpress.org/trunk@39564 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
[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
