[wp-trac] [WordPress Trac] #13318: Bug caching get_terms

WordPress Trac wp-trac at lists.automattic.com
Wed May 25 21:31:31 UTC 2011

#13318: Bug caching get_terms
 Reporter:  djudorange                   |       Owner:
     Type:  defect (bug)                 |      Status:  reopened
 Priority:  normal                       |   Milestone:
Component:  Taxonomy                     |     Version:
 Severity:  normal                       |  Resolution:
 Keywords:  has-patch reporter-feedback  |
Changes (by mfields):

 * cc: michael@… (added)
 * status:  closed => reopened
 * resolution:  wontfix =>



 I would like to reopen this ticket give a valid use case and hopefully
 provide an acceptable solution. I ran into this caching issue while adding
 functionality to my [taxonomy list
 plugin. I thought that it would be a great idea to enable users to create
 a "glossary" of terms. I have one of these set up on my site:

 For this to work correctly I needed to hook into the 'terms_clauses'
 filter to append custom SQL that would only query for terms that have
 descriptions. I passed a custom argument to get_terms() and coded the
 'terms_clauses' callback function to recognize this value.

 This worked really well in cases where this was the only call to
 get_terms() in the script. If get_terms() was called elsewhere in the
 script with the same core-supported arguments defined but without my
 custom parameter, the custom query would be used because it is stored in
 the object cache.

 I was able to piece together a hack to enable this to work that resets the
 cache key if my parameter was send:

 function taxonomy_list_shortcode_reset_cache_key( $args ) {
         if ( isset( $args['taxonomy_list_has_description'] ) ) {
                 wp_cache_set( 'last_changed', time() . '-description-
 only', 'terms' );
         else {
                 wp_cache_set( 'last_changed', time(), 'terms' );

         return $args;
 add_filter( 'get_terms_args', 'taxonomy_list_shortcode_reset_cache_key' );

 While this is not a great solution, it was the only way that I could get
 the caching to work correctly.

 The solution that I would like to offer would be to add a new default
 value to those recognized by get_terms(). This argument would have the key
 "custom" and it's value would be set to a string which could be used to
 construct a unique cache key for custom queries.

Ticket URL: <http://core.trac.wordpress.org/ticket/13318#comment:6>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software

More information about the wp-trac mailing list