[wp-trac] [WordPress Trac] #21267: Kill the serialization of $wp_filter in get_terms()

WordPress Trac noreply at wordpress.org
Wed Oct 7 04:17:00 UTC 2015


#21267: Kill the serialization of $wp_filter in get_terms()
--------------------------+------------------
 Reporter:  nacin         |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  4.4
Component:  Cache API     |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:
--------------------------+------------------
Changes (by boonebgorges):

 * keywords:  has-patch 3.9-early => has-patch
 * milestone:  Future Release => 4.4


Comment:

 >  Instead of basing the cache key on the list of callbacks attached to
 that filter, why not just use the term IDs currently returned by the
 filter?

 Yes. Imagine you have the following:

 {{{
 add_filter( 'list_terms_exclusions', function( $e ) {
     if ( is_page() ) {
         return one thing
     } else {
         return something else
     }
 } );
 }}}

 Cache is primed while looking at a page. It's now broken for all other
 uses.

 There are a couple places in this function where we're allowing filters to
 intervene: `get_terms_fields`, `get_terms_orderby`, and the Mother Filter,
 `terms_clauses`. Currently, we ignore these when building our cache key,
 but they're subject to the exact same bug.

 Using a SQL string to build a cache key is not the best thing in the
 world. For one thing, it's ugly. For another, it means running through all
 the parameter processing, even if we're going to end up hitting the cache.
 However, I think it's the only thing we can do in this case. (The
 additional processing should introduce minimal overhead - it shouldn't
 require any database queries, by the looks of things.) In this way, we
 sidestep the issue of serializing closures, and other kewl things
 discussed in this ticket.

 We still need to include a hash of the function params, because some of
 them don't reflect in the SQL query (like `child_of` and `fields`, both of
 which are processed on the fetched results).

 See [attachment:21267.3.diff].

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


More information about the wp-trac mailing list