[wp-trac] [WordPress Trac] #44779: WP_Term_Query 'search' arg escaping

[WordPress Trac]

#44779: WP_Term_Query 'search' arg escaping
---------------------------+-----------------------------
 Reporter:  stephansamuel  |      Owner:  (none)
     Type:  defect (bug)   |     Status:  new
 Priority:  normal         |  Milestone:  Awaiting Review
Component:  Taxonomy       |    Version:  4.9.8
 Severity:  normal         |   Keywords:
  Focuses:                 |
---------------------------+-----------------------------
 I'm attempting to perform a search with WP_Term_Query like this:

 {{{#!php

 $tax = ['post_tag', 'my_custom_tax'];
 $searchterm = 'my_search_term';
 $query = new WP_Term_Query(array(
   'taxonomy' => $tax,
   'number' => 8,
   'hide_empty' => false,
   'orderby' => 'name',
   'search' => $searchterm
 ));
 $results = $query->get_terms();

 }}}

 This returns no results. Upon some tracing, the request property on the
 WP_Term_Select object has a search where clause with
 {587da0c670bda03918542b984e34d59a5c55046cbd48a37d25826afffdba8b85} instead
 of % prefix and suffix around my search term (in 4 places).

 In wp-includes/class-wp-term-query.php around line 965 (the end) I added
 some logging. $like seems correct. If I do the following on the next line:

 {{{#!php

 error_log(var_export($like, true));
 error_log(var_export($wpdb->prepare('(%s)', $like), true));

 }}}

 my log shows a correct-looking $like dump and the (not correct-looking)
 long character code on the prepared string.

 Other searches, like using WP_Query, seem to work correctly. My suspicion
 tells me this may be some DB character set collation issue with the
 (prefix)_term_taxonomy table.

 My platform is MariaDB 10.0.34 through mysqlnd 5.0.12-dev-20150407
 (sockets) and PHP 7.0.30-0026 on a Linux 4.4.59 kernel running Apache
 2.4.29-0011. All WP core tables report a character set of
 utf8mb4_general_ci (seems a little odd but above my pay grade) on InnoDB.
 The DB reports a DB character set of utf8_general_ci.

 This is my first WP core bug report. I don't believe this represents a
 significant security threat (I believe PHP will faithfully handle any
 buffer overrun that this may cause, if anyone else can even reproduce it).
 Please provide any guidance you may have on getting this routed correctly.
 I am willing to contribute or help contribute to any resulting work if it
 gets that far.

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