WP_Term_Query 'search' arg escaping

[stephansamuel]

I'm attempting to perform a search with WP_Term_Query like this:

$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:

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.

[boonebgorges]

Hi @stephansamuel - Welcome to WordPress Trac, and thanks for the report.

The % escaping that you see on the WP_Term_Query request property is expected behavior. The hexadecimal hashes you see are swapped out for proper % characters at the time that $wpdb->query() is run. This is a security precaution. See ​https://make.wordpress.org/core/2017/10/31/changed-behaviour-of-esc_sql-in-wordpress-4-8-3/ and linked tickets for more details. If something is wrong, it's probably not related to the placeholder juggling.

I've attached an automated test that passes, and demonstrates that the core 'search' functionality is working as expected. If there's a problem on your installation, it's likely due to a plugin conflict - check for those that filter term queries - or because your $searchterm does not, in fact, match anything. See if you can reproduce the problem on a clean WP installation, which should help you narrow down the source of the problem.