[34247] made the 'public' paramater of `register_taxonomy()` work by blocking
requests for non-public taxonomy archives during `parse_request()`. Blocking
taxonomy archive requests this late means that it's impossible to register an
independent query var that matches the slug of a non-public taxonomy. By
moving the block to `register_taxonomy()` - not allowing these taxonomies to
register their query vars in the first place - we free up the slug for other
use. In addition, we free up a bit of processing (no need to look for the query
var in `parse_request()` and better parallel the way non-public post types
work. See `register_post_type()`.
Non-public taxonomy archives that are requested using `?taxonomy=tax_name` are
still blocked during `parse_request`. It's only custom query vars -
`?tax_name=term` - that are affected by this change.
Props mboynes.
Fixes#21949.
Built from https://develop.svn.wordpress.org/trunk@35333
git-svn-id: http://core.svn.wordpress.org/trunk@35299 1a063a9b-81f0-0310-95a4-ce76da25c4cd
[34997] caused `get_term()` to return an error object in the case when
`$taxonomy` did not match the taxonomy of the located term. This was an
inadvertant change from the previous behavior, when `get_term()` would return
null in these cases.
Props dlh.
See #14162. Fixes#34332.
Built from https://develop.svn.wordpress.org/trunk@35227
git-svn-id: http://core.svn.wordpress.org/trunk@35193 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously, the cache key included a serialization of `list_terms_exclusions`
callbacks, to ensure that the cache was differentiated properly for different
uses of the `list_terms_exclusions` filter. This strategy was flawed in a
couple of ways: serialization doesn't work equally well for all callable types;
the serialization required reaching into the `$wp_filter` global; serializing
the callback itself didn't properly account for the possibility that the
callback might return different values in different contexts; the cache key
didn't account for other filters that similarly affect the cached values, such
as `terms_clauses`.
We skirt all these issues by concatenating the cache key using the SQL query
string, which will reflect all filters applied earlier in `get_terms()`.
Props boonebgorges, wonderboymusic.
Fixes#21267.
Built from https://develop.svn.wordpress.org/trunk@35120
git-svn-id: http://core.svn.wordpress.org/trunk@35085 1a063a9b-81f0-0310-95a4-ce76da25c4cd
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
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
This function attempts to read from the relationship cache, and uses any data
it finds. If it finds no data, it does a query for the data it needs. Since we
are going to the trouble to query for the relationships, and since we are
already using cached data when available, let's go ahead and cache it for
later use.
Props joehoyle, boonebgorges.
Fixes#32044.
Built from https://develop.svn.wordpress.org/trunk@34812
git-svn-id: http://core.svn.wordpress.org/trunk@34777 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`wp_insert_term()` doesn't allow the creation of a term when the term `name`
is the same as another term in the same hierarchy level of the same taxonomy.
Previously, this duplicate check used `get_term_by( 'name' )`, which uses the
database collation to determine sameness. But common collations do not
distinguish between accented and non-accented versions of a character. As a
result, it was impossible to create a term 'Foo' if a sibling term with an
accented character existed.
We address this problem by using `get_terms()` to do the duplicate check. This
query returns all potentially matching terms. We then do a stricter check
for equivalence in PHP, before determining whether one of the matches is
indeed a duplicate.
Props boonebgorges, tyxla, geza.miklo, mehulkaklotar.
Fixes#33864.
Built from https://develop.svn.wordpress.org/trunk@34809
git-svn-id: http://core.svn.wordpress.org/trunk@34774 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Termmeta cache priming was throwing database errors on installations that had
not yet gone through the database update routine. To avoid errors in all cases,
the check has been added to all termmeta functions. These checks will be
removed in a future version of WordPress. (Hang on to your hats!)
Fixes#34091.
Built from https://develop.svn.wordpress.org/trunk@34718
git-svn-id: http://core.svn.wordpress.org/trunk@34682 1a063a9b-81f0-0310-95a4-ce76da25c4cd
[34529] introduced lazyloading for the metadata belonging to terms matching
posts in the main `WP_Query`. The current changeset improves this technique
in the following ways:
* Term meta lazyloading is now performed on the results of all `WP_Query` queries, not just the main query.
* Fewer global variable touches and greater encapsulation.
* The logic for looping through posts to identify terms is now only performed once per `WP_Query`.
Props dlh, boonebgorges.
See #34047.
Built from https://develop.svn.wordpress.org/trunk@34704
git-svn-id: http://core.svn.wordpress.org/trunk@34668 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The 'last_changed' incrementor is used to invalidate the `get_terms()` query
cache. Since `get_terms()` queries may reference 'meta_query', changing term
metadata could change the results of the queries. So we invalidate the cache
on add, delete, and update.
See #10142.
Built from https://develop.svn.wordpress.org/trunk@34538
git-svn-id: http://core.svn.wordpress.org/trunk@34502 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Adds a new table to the database schema (`wp_termmeta`), and a set of
`*_term_meta()` API functions. `get_terms()` and `wp_get_object_terms()`
now also support 'meta_query' parameters, with syntax identical to other
uses of `WP_Meta_Query`.
When fetching terms via `get_terms()` or `wp_get_object_terms()`, metadata for
matched terms is preloaded into the cache by default. Disable this behavior
by setting the new `$update_term_meta_cache` paramater to `false`.
To maximize performance, within `WP_Query` loops, the termmeta cache is *not*
primed by default. Instead, we use a lazy-loading technique: metadata for all
terms belonging to posts in the loop is loaded into the cache the first time
that `get_term_meta()` is called within the loop.
Props boonebgorges, sirzooro.
See #10142.
Built from https://develop.svn.wordpress.org/trunk@34529
git-svn-id: http://core.svn.wordpress.org/trunk@34493 1a063a9b-81f0-0310-95a4-ce76da25c4cd
If your plugin or site does rely on this behaviour, the arguments that are passed to `register_taxonomy()` should be altered so that `show_ui` is `true`, and arguments such as `show_in_menu` and `show_in_nav_menus` are false.
Fixes#33938
Built from https://develop.svn.wordpress.org/trunk@34359
git-svn-id: http://core.svn.wordpress.org/trunk@34323 1a063a9b-81f0-0310-95a4-ce76da25c4cd
[13216] introduced the 'public' argument for `register_taxonomy()`. This param
was used to set defaults for 'show_ui' and a number of other params, but it
never did anything itself.
With this changeset, taxonomies registered with `public=false` will no longer
be queryable on the front end, ie via taxonomy archive queries.
Props wpsmith, ocean90, nacin, ericlewis, boonebgorges.
Fixes#21949.
Built from https://develop.svn.wordpress.org/trunk@34247
git-svn-id: http://core.svn.wordpress.org/trunk@34211 1a063a9b-81f0-0310-95a4-ce76da25c4cd
[29128] introduced updated documentation for the `'orderby'` parameter of
`get_terms()`. The new documentation mistakenly said that 'term_id' was a valid
orderby value. The current changeset makes that fantasy...A REALITY.
Props ixkaito.
Fixes#33726.
Built from https://develop.svn.wordpress.org/trunk@33903
git-svn-id: http://core.svn.wordpress.org/trunk@33872 1a063a9b-81f0-0310-95a4-ce76da25c4cd
