[wp-trac] [WordPress Trac] #39315: WP_Tax_Query::transform_query() double escapes name term arguments

[WordPress Trac]

#39315: WP_Tax_Query::transform_query() double escapes name term arguments
--------------------------+-----------------------------
 Reporter:  bcworkz       |      Owner:
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Query         |    Version:  4.7
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 As [https://wordpress.org/support/topic/wp_query-does-not-fetch-
 posts/#post-8562253 reported] in Support Forums by @expert1

 When making a new `WP_Query` that includes a "tax_query" argument
 involving a term name that has characters requiring escaping, such as
 apostrophes, `WP_Tax_Query::transform_query()` double escapes the term
 name so that the subsequent query always fails. The resulting SQL string
 includes `WHERE 0=1` due to the double escaping.

 The term is first escaped by `wp_filter_kses()` which is hooked into the
 "edit_term_name" filter of `sanitize_term_field()` which is called on
 [trac:source:trunk/src/wp-includes/class-wp-tax-query.php#L626 line 626]
 of wp-includes/class-wp-tax-query.php. On return the term is escaped again
 with `esc_sql()` on the same line.

 I'm not sure if it makes more sense to remove the `esc_sql()` call or to
 hook in `wp_kses()` instead of `wp_filter_kses()` for the "edit_term_name"
 filter. If the latter, we need to run the term through `stripslashes()`
 before passing it to the filter callbacks. I'm unsure how that may affect
 other filter callbacks. (`sanitize_text_field()` and `_wp_specialchars()`
 by default)

--
Ticket URL: <https://core.trac.wordpress.org/ticket/39315>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform