If it used like_escape, there would need to be a different way of passing the "%"s instead of meta_value, as if it does like_escape( $meta_value ) the "%" will be escaped.

In terms of not doing it in favour of using posts_join, I feel is a bit of a workaround, hooking into posts_join, checking if the join has been added, then hooking into posts_where and inserting the LIKE statement seems like a lot of work compared to a proper implementation of using LIKE as a meta_compare. Especially as currently the posts_join and posts_where filters don't give you access to the WP_Query object it is a pain to check for query vars etc (global $wp_query not included).

In terms of not doing it in favour of using posts_join, I feel is a bit of a workaround, hooking into posts_join, checking if the join has been added, then hooking into posts_where and inserting the LIKE statement seems like a lot of work compared to a proper implementation of using LIKE as a meta_compare. Especially as currently the posts_join and posts_where filters don't give you access to the WP_Query object it is a pain to check for query vars etc (global $wp_query not included).

Just in case you're not aware that you can put AND clauses in a JOIN statement, your example would be:

JOIN $wpdb->postmeta as my_plugin_meta
ON my_plugin_meta.post_id = $wpdb->posts.ID
AND my_plugin_meta.meta_key = 'url'
AND my_plugin_meta.meta_value LIKE '$my_sanitized_like_statement'

Just in case you're not aware that you can put AND clauses in a JOIN statement, your example would be:

Ahh I was not aware you could do that, thanks!

you can check the WP query in your plugin's function:

Again, learned another thing here, didn't know the current query was stored in $wp_the_query (as I presume from the example it is)

Even so, not included LIKE in meta_compare on the grounds that there is currently no function to easily sanitize the string seems wrong. Surely WP_Query should be as powerful as possible (within reason, and not getting in the way of ease of use) as WordPress is being used for more abstract uses, especially when it comes to post_meta. Adding less than 20 characters to the query class to allow this, potentially very useful enhancement (escape_like aside, as it seems that needs attention regardless).

Just thinking out loud, but it just seems like a natural progression for the class.

Even so, not included LIKE in meta_compare on the grounds that there is currently no function to easily sanitize the string seems wrong.

sure. basically, what's needed is to make sure than LIKE and NOT LIKE properly handle comparisons that include \_ or \% in the url. these would catch literal _ and % in strings without being treated as wildcards. Since we're using single quotes, the \ might need to be double-escaped to work (i.e.