#56055 closed defect (bug) (duplicate)
Wrong cache created in WP_Term_Query class
Reported by: | kubiq | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | critical | Version: | 6.0 |
Component: | Taxonomy | Keywords: | |
Focuses: | Cc: |
Description
When you call the same get_terms( $args )
multiple times, then the second (or every other call) will return wrong results - they will contain also empty terms
You can easily test this on any taxonomy with some empty term
<?php echo '1. call:'; echo '<pre>' . print_r( get_terms(array( 'taxonomy' => 'product_cat', 'parent' => 0 )), 1 ) . '</pre>'; echo '2. call:'; echo '<pre>' . print_r( get_terms(array( 'taxonomy' => 'product_cat', 'parent' => 0 )), 1 ) . '</pre>';
logically the output should be same in the 1.call and also in 2. call, but it's not
SOLUTION:
In get_terms
function inside WP_Term_Query
class at the end there is
wp_cache_add( $cache_key, $terms, 'terms' );
but $terms
variable contains all terms even if you have hide_empty
set to TRUE
*$term_objects
is the correct variable that contains correct terms and it is also used in next lines
it can be fixed by getting terms ids from $term_objects
variable eg.
<?php $correct_terms = array_map(function( $term ){ return (object)array( 'term_id' => $term->term_id ); }, $term_objects);
and replace it in cache function
<?php wp_cache_add( $cache_key, $correct_terms, 'terms' );
Change History (9)
This ticket was mentioned in Slack in #core by kubiq. View the logs.
2 years ago
This ticket was mentioned in Slack in #core by kubiq. View the logs.
2 years ago
#5
@
2 years ago
- Keywords close added; needs-patch removed
Ah, it looks like it's probably a duplicate of #55837.
as per today's bug scrub, @kubiq is testing the issue on 6.1 alpha.
This ticket was mentioned in Slack in #core by kubiq. View the logs.
2 years ago
#7
@
2 years ago
- Keywords close removed
Removing close
keyword as it appears that the issue is still valid on 6.1-alpha.
Related: #55837
Thanks for finding this @kubiq!
The proposed solution looks good to me. Now we'll need a patch or a PR for this ticket :)
As per today's bug scrub, let's move this ticket to WP 6.0.1 as it appears it was introduced in 6.0.