Make WordPress Core

Opened 4 years ago

Last modified 4 years ago

#49799 new defect (bug)

get_the_terms() object term cache check too strict?

Reported by: dingo_d's profile dingo_d Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 2.3
Component: Taxonomy Keywords: reporter-feedback needs-unit-tests
Focuses: Cc:


I ran into a weird issue when doing integration tests on one of a client's project.

I was setting up custom post and custom taxonomy from the factory (for posts I used the default one, and for custom taxonomy I have created my own factory that extends WP_UnitTest_Factory_For_Term), set everything up, but the part of the plugins code that used get_the_terms returned nothing. So after racking my brains, I tried wp_get_post_terms, and lo and behold, this worked (the test posts had assigned terms for them, I checked before invoking my function I needed to test using get_the_terms).

So something was up with caching. I started to dig and it turned out that

$terms = get_object_term_cache( $post->ID, $taxonomy );

inside wp-includes/category-template.php

returned an empty array.

Now, since the line 1246 says

if ( false === $terms ) {

The empty array, while being a falsy value, it's not a false value (, so the above check will return false and the returned value from the get_the_terms function will be false.

So when I 'loosened' the condition in my test suite WP, the $terms = wp_get_object_terms( $post->ID, $taxonomy );
works, and I get my terms inside the tests.

If the condition is loosened, nothing seems to be lost in terms of checking the emptiness of the terms from the term object cache (if it's full, it's false all the times

Now, on the face value, this could be the oddity of the test suite (which in my case is set up using wpcli scaffold command), but I'm thinking that changing this requirement cannot hurt (from what I can tell) in the long run.

Attachments (1)

49799.diff (546 bytes) - added by dingo_d 4 years ago.
Patch with the fix

Download all attachments as: .zip

Change History (7)

This ticket was mentioned in PR #211 on WordPress/wordpress-develop by dingo-d.

4 years ago

Loosened the condition to check the terms fetched fro mthe object term cache. The cache can return an empty array, which is a falsy value, so the get_the_terms will return false value.

Trac ticket:

4 years ago

Patch with the fix

dingo-d commented on PR #211:

4 years ago

Also, maybe a good thing to note is that I'm assigning the terms in my tests using wp_set_object_terms(); function. The same thing happened when I tried wp_set_post_terms(), so it could be something related to that (test env could mess with the object caching?)

This ticket was mentioned in Slack in #themereview by dingo_d. View the logs.

4 years ago

#4 follow-up: @joyously
4 years ago

Is this another fallout from #48965 (similar to #49853)?

This ticket was mentioned in Slack in #core by joyously. View the logs.

4 years ago

#6 in reply to: ↑ 4 @SergeyBiryukov
4 years ago

  • Keywords reporter-feedback needs-unit-tests added; dev-feedback 2nd-opinion has-patch removed
  • Version changed from 5.4 to 2.3

Thanks for the ticket!

Replying to joyously:

Is this another fallout from #48965 (similar to #49853)?

Doesn't seem like that. This line was added in [5598] / #4189 for WordPress 2.3, moved to the newly created get_the_terms() function in [7520] / #6357, and has not changed much since then.

$terms = get_object_term_cache( $post_id, $taxonomy );

if ( false === $terms ) {
	$terms = wp_get_object_terms( $post_id, $taxonomy, $args );

This pattern is not specific to get_the_terms(), it's used in quite a few other places in core:

  • get_attachment_fields_to_edit()
  • get_compat_media_markup()
  • get_terms_to_edit()
  • get_inline_data()
  • wp_queue_posts_for_term_meta_lazyload()
  • get_the_taxonomies()
  • is_object_in_term()

So while there indeed might be an issue here, this doesn't appear to be a regression in 5.4.

The false === ... check is specifically used to ensure the cache is empty. Making the check less strict would go against the coding standards and doesn't seem like the correct way to fix this.

Instead, a check for an empty array should be added if necessary. Before making any changes though, it would be helpful to have some unit tests to reproduce the issue.

Note: See TracTickets for help on using tickets.