[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