I’ve encountered a severe problem with the basic search functionality of wordpress in my woocommerce store (behavior of WP_Query::parse_search()).
The story:
The basic search does not look for product attributes values matching the string, so I needed a fix to let the users find what they are looking for (e.g. color of an item). My approach was, to keep the search string consistent (as the user typed it), look for the color terms, add them as a taxonomy query at runtime and also fill them into the stopwords array.
So a user gets “T-Shirt green” shown in his search box and green is ignored (because it would yield zero results in content/excerpt). I am not able to buy one of the many relevance search plugins because they do not work together with my ajax filters.
The problem:
If a user seaches only for a color (e.g. “green”) the search-string is matched against the stopwords and a very inconsistent behaviour kicks in:
https://developer.www.ads-software.com/reference/classes/wp_query/parse_search/
line 1267 + 1268
if ( empty( $q['search_terms'] ) || count( $q['search_terms'] ) > 9 )
$q['search_terms'] = array( $q['s'] );
The search query is not sent as “empty” (as someone manipulating stopwords would expect = all results) but it ignores the stopwords.
Possible solution:
I would like to be able to choose between two options, where the behavior now is the default functionality:
– treat all-stopword / long search as simple string (like it is now)
– return all posts as result when only stopwords are used (like empty search)
I am by no means a professional programmer but maybe you can add a filter to line 1268, I really don’t want to mess with core files and keep it update safe.
Thank you for your time and effort,
Chris
Edit: My code can be seen at:
]]>The query object is passed to your callback. The original search text is available in WP_Query::query_vars[‘s’]
]]>