The data stored in the cache should be raw database query results, not
`WP_Term` objects (which may be modified by plugins, and may contain additional
properties that shouldn't be cached).
If term relationships caches were handled in `wp_get_object_terms()` - where
a database query takes place - it would be straightforward to cache raw data.
See #34239. Since, in fact, `get_the_terms()` caches the value it gets from
`wp_get_object_terms()`, we need a technique that allows us to get raw data
from a `WP_Term` object. Mirroring `WP_User`, we introduce a `data` property
on term objects, which `get_the_terms()` uses to fetch cacheable term info.
Fixes#34262.
Built from https://develop.svn.wordpress.org/trunk@35032
git-svn-id: http://core.svn.wordpress.org/trunk@34997 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The test, introduced in [33724], was intended to demonstrate the behavior of
`example.com?tag=foo` routing. But an error in the test setup meant that a
URL-encoded tag object was being set as the value of 'tag'. Due to a quirk in
the way that `parse_request()` parses query vars, an object value for 'tag'
would inadvertently produce correct results in certain cases. But it's not a
usage we actively support, and it's not what was meant to be tested.
See #33532, #34262.
Built from https://develop.svn.wordpress.org/trunk@35030
git-svn-id: http://core.svn.wordpress.org/trunk@34995 1a063a9b-81f0-0310-95a4-ce76da25c4cd
A valid `$network_id` or `null`/`false` is expected as the first parameter for `_network_option()`. If something other than that is passed, we immediately return `false` rather than attempting to guess what network was intended.
See #28290.
Built from https://develop.svn.wordpress.org/trunk@35025
git-svn-id: http://core.svn.wordpress.org/trunk@34990 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously, an value matching `empty()` would have been bypassed in favor of the default setting for 100MB.
Related #19538, r19639, r19652, where we saw the bug, fixed the bug, and then unfixed the bug so that it was not a surprise in a point release.
See #34037.
Built from https://develop.svn.wordpress.org/trunk@35016
git-svn-id: http://core.svn.wordpress.org/trunk@34981 1a063a9b-81f0-0310-95a4-ce76da25c4cd
As the number of multidimensional settings (serialized options and theme mods) increase for a given ID base (e.g. a widget of a certain type), the number of calls to the `multidimensional` methods on `WP_Customize_Setting` increase exponentially, and the time for the preview to refresh grows in time exponentially as well.
To improve performance, this change reduces the number of filters needed to preview the settings off of a multidimensional root from N to 1. This improves performance from `O(n^2)` to `O(n)`, but the linear increase is so low that the performance is essentially `O(1)` in comparison. This is achieved by introducing the concept of an "aggregated multidimensional" setting, where the root value of the multidimensional serialized setting value gets cached in a static array variable shared across all settings.
Also improves performance by only adding preview filters if there is actually a need to do so: there is no need to add a filter if there is an initial value and if there is no posted value for a given setting (if it is not dirty).
Fixes#32103.
Built from https://develop.svn.wordpress.org/trunk@35007
git-svn-id: http://core.svn.wordpress.org/trunk@34972 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In all three cases, the functions can accept a post ID, a `WP_Post` object, or a falsey value, which defaults to the value of the global `$post`. Switching to `$post` in this context allows the parameters to better self-document and removes ambiguity in the code they are subsequently used in.
Props chriscct7 for the initial patch.
See #34234.
Built from https://develop.svn.wordpress.org/trunk@35001
git-svn-id: http://core.svn.wordpress.org/trunk@34966 1a063a9b-81f0-0310-95a4-ce76da25c4cd
A side effect of this change is that terms stored in the cache no longer have
an `object_id` associated with them. Previously, `object_id` had always been
cached when the term cache was populated via `wp_get_object_terms()`, a
strategy that was mostly harmless but still incorrect.
See #14162.
Built from https://develop.svn.wordpress.org/trunk@34999
git-svn-id: http://core.svn.wordpress.org/trunk@34964 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`get_term()` now returns a `WP_Term` object, instead of a `stdClass` object.
Cache support and sanitization filters for individual terms are now more
centralized. For example, `get_term_by()` is able to cast results of its query
to a `WP_Term` object by passing it through `get_term()`.
The `$taxonomy` parameter for `get_term()` is now optional, as terms ought to
be unique to a taxonomy (ie, shared terms no longer exist). In cases where
`get_term()` detects that the term matching the specified term_id is from the
wrong taxonomy, it checks to see if you've requested a shared term, and if so,
it splits the term. This is used only for fallback purposes.
The elimination of shared terms allows the caching strategy for terms to be
simplified. Individual terms are now cached in a single 'terms' bucket.
Props flixos90, boonebgorges, scribu, dipesh.kakadiya.
See #14162.
Built from https://develop.svn.wordpress.org/trunk@34997
git-svn-id: http://core.svn.wordpress.org/trunk@34962 1a063a9b-81f0-0310-95a4-ce76da25c4cd
These H5 (heading level 5) don't allow for a good headings hierarchy and shouldn't be headings in the first place. Each group of options has now its own fieldset and legend.
In `render_screen_options()`, introduce two new "render" methods: `render_meta_boxes_preferences()` and `render_list_table_columns_preferences()` for consistency with already existing render methods and cleaner code.
Props joedolson, afercia.
Fixes#33646.
Built from https://develop.svn.wordpress.org/trunk@34991
git-svn-id: http://core.svn.wordpress.org/trunk@34956 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The 'do not' is converted to "don't" because "you" is third-person plural, and 'does not' is converted to "doesn't" because `localhost` is third-person singular. While both are "negative" contractions, we often write this way in WordPress to provide a friendlier tone. That's your English grammar lesson for the day.
Props ankit-k-gupta, iamfriendly.
Fixes#30317.
Built from https://develop.svn.wordpress.org/trunk@34987
git-svn-id: http://core.svn.wordpress.org/trunk@34952 1a063a9b-81f0-0310-95a4-ce76da25c4cd