I understand, thank you.
Unfortuantely I was right – the search results page is using multiple sub-queries, I just checked the results page source. I guess this is for organization purposes or so.
However this creates the massive issue. The search results should always originate from the original WordPress search query, not from custom queries, that is a bad practice. The reason behind it is, that search plugins can hardly determine which queries to overtake, and they expect a single query for the results. This is because the pagination, the number of results and many other variables.
Currently what happens is, that multiple search queries being executed within the actual search loop. When the soft-check option is active, the plugin tries to overtake on these queries as well, which is the source of the problem.
If you can’t avoid using these subqueries, then my suggestion is to change these queries to non-search queries instead – that may actually work without conflict. For the arguments the “post_type” and the “post__in” from the current page without the “s” arguments.
global $wp_query;
$post_ids = wp_list_pluck( $wp_query->posts, 'ID' );
$args = array(
'post_type'=> 'post_type',
'post__in' = $post_ids,
'showposts' => -1
);
// Custom query.
$query = new WP_Query($args);
// Check that we have query results.
if ( $query->have_posts() ) {
// Start looping over the query results.
while ( $query->have_posts() ) {
$query->the_post();
// Contents of the queried post results go here.
}
}
// Restore original post data.
wp_reset_postdata();Something like this, but it should not be too difficult, your programmer can very likely figure it out. I could not see the wp_reset_postdata() call inbetween the queries, which is also very important to maintain the proper structure. This may needs a bit of experimenting, but I am already a bit out of the plugin support boundaries, but I hope this helps anyways.