[wp-trac] [WordPress Trac] #63877: WP_Term_Query::get_terms() - check return value of get_term()
WordPress Trac
noreply at wordpress.org
Mon Aug 25 20:05:15 UTC 2025
#63877: WP_Term_Query::get_terms() - check return value of get_term()
--------------------------+-----------------------------
Reporter: josephscott | Owner: (none)
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Taxonomy | Version: trunk
Severity: normal | Keywords:
Focuses: |
--------------------------+-----------------------------
Deep inside of `WP_Term_Query::get_terms()` there is a `get_term()` call
that assumes it will always get a `WP_Term` object back. Even though
`get_term()` is documented -
https://developer.wordpress.org/reference/functions/get_term/ - as being
able to return `WP_Term|array|WP_Error|null`. I'm running into cases
where it returns `null`, generating a warning like:
{{{
Attempt to read property "count" on null
}}}
Because it always tries to look at `$child->count`, without ever checking
the return value - https://github.com/WordPress/wordpress-
develop/blame/trunk/src/wp-includes/class-wp-term-query.php#L851-L854
We can avoid that warning, and keep the existing behavior, with an
additional check. `WP_Term_Query::populate_terms()` for example uses
`instanceof`, which could also be done here - https://github.com/WordPress
/wordpress-develop/blob/trunk/src/wp-includes/class-wp-term-
query.php#L1140-L1142
Here is a simplified test of this condition - https://3v4l.org/E4uk7 -
that confirms the same result for the `if` condition and that the warning
no longer happens.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/63877>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list