`get_category_link()` is a wrapper for `get_term_link()`. Using the
unwrapped function makes more sense semantically (it's taxonomy-
agnostic) and it's also more parsimonious (the `WP_Error` check in
`get_category_link()` is redundant with similar checks just before
in `get_term_link()`).
Props keesiemeijer.
Fixes#17069.
Built from https://develop.svn.wordpress.org/trunk@39593
git-svn-id: http://core.svn.wordpress.org/trunk@39533 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In addition to `wp_list_filter()` for filtering a list of objects, and `wp_list_pluck()` for plucking a certain field out of each object in a list, this new function can be used for sorting a list of objects by specific fields. These functions are now all contained within the new `WP_List_Util()` class and `wp_list_sort()` is used in various parts of core for sorting lists.
This was previously committed in [38859] but got reverted in [38862] and [38863]. To fix the previous issues, `wp_list_sort()` supports now an additional argument to preserve array keys via `uasort()`.
Props flixos90, DrewAPicture, jorbin.
Fixes#37128.
Built from https://develop.svn.wordpress.org/trunk@38928
git-svn-id: http://core.svn.wordpress.org/trunk@38871 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In addition to `wp_list_filter()` for filtering a list of objects, and `wp_list_pluck()` for plucking a certain field out of each object in a list, this new function can be used for sorting a list of objects by specific fields. These functions are now all contained within the new `WP_List_Util()` class and `wp_list_sort()` is used in various parts of core for sorting lists.
Props flixos90, DrewAPicture, jorbin.
Fixes#37128.
Built from https://develop.svn.wordpress.org/trunk@38859
git-svn-id: http://core.svn.wordpress.org/trunk@38802 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously, objects containing all data about a term were stored in each
object's term cache. Besides being wasteful, this approach caused invalidation
issues, as when a modified term count required a flush for all objects
belonging to the term.
Backward compatibility is maintained for plugins that continue to put object
data directly into the `{$taxonomy}_relationships` cache bucket.
Fixes#36814.
Built from https://develop.svn.wordpress.org/trunk@37573
git-svn-id: http://core.svn.wordpress.org/trunk@37541 1a063a9b-81f0-0310-95a4-ce76da25c4cd
[34696] introduced a regression whereby comma-separated values for 'exclude'
and 'exclude_tree' would be handled improperly when merging the two parameters,
resulting in category IDs being incorrectly dropped from the combined array.
Props gblsm, hnle.
Fixes#35156.
Built from https://develop.svn.wordpress.org/trunk@36005
git-svn-id: http://core.svn.wordpress.org/trunk@35970 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`wp_get_object_terms()` can return a `WP_Error` object. As such, the
`get_the_terms()` cache wrapper should handle them properly. To wit:
* Don't try to map an error object to `get_term()`. Introduced in [35032].
* Don't cache an error object as taxonomy relationships. Introduced in at least [16487], maybe earlier.
Props stephenharris.
Fixes#34723.
Built from https://develop.svn.wordpress.org/trunk@35850
git-svn-id: http://core.svn.wordpress.org/trunk@35814 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
The 'exclude_tree' parameter must be compatible with 'hierarchical';
previously, 'hierarchical' canceled it out. This changeset also makes it so
that 'exclude_tree' is compatible with 'exclude'. When both are passed, and
'hierarchical' is true, the descendant trees of terms in both parameters will
be excluded from matched terms.
Props tott, webord, MikeHansenMe.
Fixes#12981.
Built from https://develop.svn.wordpress.org/trunk@34696
git-svn-id: http://core.svn.wordpress.org/trunk@34660 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Used to filter categories as structured data, before building markup in
`get_the_category_list()`.
We use this filter in addition to upstream filters (such as
'get_the_categories'`) because those upstream filters are used in numerous
contexts, while `'the_category_list'` is always used for generating markup
for display.
Props KevinB, ericlewis, SergeyBiryukov, DrewAPicture.
Fixes#9227.
Built from https://develop.svn.wordpress.org/trunk@34625
git-svn-id: http://core.svn.wordpress.org/trunk@34589 1a063a9b-81f0-0310-95a4-ce76da25c4cd
When generating a `<ul>` using `wp_list_categories()`, a title `<li>` element
is put at the top of the term list. Current behavior is that this title `<li>`
appears even when no terms are found. The new `hide_title_if_no_cats` param
allows developers to specify that the title should be hidden when the term list
is empty.
Props vilkatis.
Fixes#33460.
Built from https://develop.svn.wordpress.org/trunk@33764
git-svn-id: http://core.svn.wordpress.org/trunk@33732 1a063a9b-81f0-0310-95a4-ce76da25c4cd
As of [32484], `wp_dropdown_categories()` uses the `$value_field` value to
decide whether a given `<option>` should be 'selected'. However, `$value_field`
can refer to a value that is a string, such as a category's slug. This causes
problems when doing a loose comparison (`==`) with the value of the `'selected'`
parameter, which defaults to `0`, because when doing a loose comparison
between an integer and a string, PHP will cast the string to an integer. This
creates false matches, resulting in `<option>` elements getting a 'selected'
attribute incorrectly.
We address the issue by casting the comparison values to strings, and then
using the strict comparison operator `===`.
Fixes#33452 for trunk.
Built from https://develop.svn.wordpress.org/trunk@33681
git-svn-id: http://core.svn.wordpress.org/trunk@33648 1a063a9b-81f0-0310-95a4-ce76da25c4cd