[wp-trac] [WordPress Trac] #42771: WP_Term::get_instance() regression for non-category terms queried with 'category' taxonomy

WordPress Trac noreply at wordpress.org
Fri Dec 1 20:52:25 UTC 2017


#42771: WP_Term::get_instance() regression for non-category terms queried with
'category' taxonomy
--------------------------+--------------------
 Reporter:  markjaquith   |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  high          |   Milestone:  4.9.2
Component:  Taxonomy      |     Version:  4.9
 Severity:  major         |  Resolution:
 Keywords:                |     Focuses:
--------------------------+--------------------
Changes (by boonebgorges):

 * milestone:  Awaiting Review => 4.9.2


Comment:

 Thanks for opening the ticket.

 #42717 and #46205 are definitely related, and #42691 probably is. #42732
 appears to be unrelated; see
 https://core.trac.wordpress.org/changeset/40918.

 If I'm understanding correctly - and setting aside the regression for a
 moment - [40979] fixes an inconsistency in the way taxonomy mismatches
 were previously handled. On an empty cache, a database query would take
 place, which would fetch items from all taxonomies; if a term in the
 proper tax wasn't found, `get_instance()` would return false. But if the
 cache were populated, it'd return the term. After [40979], the behavior is
 consistent regardless of the cache state. See the attached tests, and try
 running them with [40979] rolled back. In cases where a regression is
 reported, it just so happens that the reporters were testing against a
 case where the cache in question had already been populated by some other
 query on the page.

 I wonder if we can address the regression by changing the calls to
 `get_term()` so that they don't specify a taxonomy. See the attached patch
 for `get_category_link()`. This too is technically a regression from
 pre-4.9 behavior (see the comment above about caching). But it'll probably
 fix most problems in the wild, leaving only the category template
 functions as the exceptions, rather than hardcoding an exception deep in
 the API.

 @markjaquith Your wisdom here would be appreciated :-D

--
Ticket URL: <https://core.trac.wordpress.org/ticket/42771#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list