[wp-trac] [WordPress Trac] #57966: High number of call to sanitize_term in wp_queue_posts_for_term_meta_lazyload

WordPress Trac noreply at wordpress.org
Fri Mar 31 17:48:02 UTC 2023


#57966: High number of call to sanitize_term in
wp_queue_posts_for_term_meta_lazyload
--------------------------+---------------------------
 Reporter:  spacedmonkey  |       Owner:  spacedmonkey
     Type:  enhancement   |      Status:  assigned
 Priority:  normal        |   Milestone:  6.3
Component:  Taxonomy      |     Version:  6.2
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  performance
--------------------------+---------------------------

Comment (by spacedmonkey):

 @joemcgill For context. The old version of this function used
 [https://developer.wordpress.org/reference/functions/get_object_term_cache/
 get_object_term_cache]. In that function, it does
 [https://github.com/WordPress/wordpress-
 develop/blob/4d6fae0331bd32bd0cf449c796513a22540f65c0/src/wp-
 includes/taxonomy.php#L3687-L3695 this]. To ensure that backwards
 compatibility is maintained, I copied this logic over, but looking at the
 code again, I am not sure it is needed.

 Calling get_term here does two things.
 1. Check the taxonomy exists.
 2. Check the term exists.

 Why are either of these checks needed? The code in the function, gets
 taxonomies assigned to the current posts. But if had a taxonomy from say a
 plugin and then deactivated that plugin, then it would not be registered
 and not be looked up, so the taxonomy look up is unrequired IMO. As for
 the ID, I don't see why the term would come back as part of the
 relationship to the post, if the term was deleted, but maybe some weird
 caching issue. What is the problem is asking for a term meta for a term
 that doesn't exist? Either will never be rendered or more than likely
 nothing will return. As the lookup for term meta is down in one database
 query, it is just one id in a list of others. As a key lookup, it will
 quickly return nothing.

 Unless I am missing something, these checks seem pointless, as we already
 have the id we need,just pass it to the term meta lazy load queue and
 forget about it. It also worth noting that term meta is not heavily used,
 that the likelihood of this ever being a problem seems low.

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


More information about the wp-trac mailing list