Support Forums

Looking for support? You can access the support system via your account.

Forums Forums Search & Filter Pro Query vars and results order don't match

Viewing 10 posts - 1 through 10 (of 11 total)
  • dpolonsky
    #206917

    I have a WP search bar that when the user types in the keyword, it directs them to the search.php template. There, the results display and there is a Search & Filter Pro form above the results.

    The good news is that for the same keyword, both the WP search and S&F Pro return the same number of results. The bad new is, that the order isn’t matching. I’m not sure why yet.

    I’m using the sf_edit_query_args hook to alter the query arguments for S&F. I’ve made it so the query vars from S&F match to the WP search which I’m also altering using pre_get_posts.

    The only thing that does not match, is that S&F has the post__in arg with IDs stored whereas the default WP search has it as an empty array. Could this be why the order of the results from S&F pro differ from that of the WP search results? I tried setting it to an empty array on the hook, and set the priority to 15 but it doesn’t seem to overwrite it.

    If it’s helpful, I’ve set these query args both for WP search and S&F search:

    order = DESC
    post__not_in = some IDs I’ve passed
    post_in = empty array (only for S&F where I’m trying to force it, WP already does this)
    orderby = ‘meta_value date’
    post_status = ‘publish’
    meta_query – Relation: OR, checks two keys whether they EXISTS/NOT EXISTS

    It seems like the meta query that’s not kicking in. On the WP search, it takes the posts with the post meta I’m looking for that exists, and places them on top of the results with the date/desc as the secondary sorting. Then the remaining results follow also in date/desc order.

    The S&F Pro results don’t seem to be doing that correctly. Anything I can try or other args/query vars I can check?

    Thanks.

    Trevor Moderator
    #206932

    The sf_edit_query_args hook will ignore any post__in (did you use 2 underscores in yours?) argument you pass, but sorting should work.

    Can you post up the actual code you are using (inside code back ticks)?

    dpolonsky
    #206964
    This reply has been marked as private.
    Trevor Moderator
    #207055

    If you are using the Custom display results method, did you try adding our filter to the pre_get_posts? Like this:

    function pre_get_posts_function($query)
    {
    //this would be a pre_get_posts you already have in place somewhere
    //then set <code>search_filter_id</code>
    $query->set("search_filter_id", 123);
    }
    add_action( 'pre_get_posts', array($this, 'pre_get_posts_function') );
    dpolonsky
    #207085

    I commented out the function that used the sf_edit_query_args hook. Then I added the query set to my existing modify_search_results_order function that’s using pre_get_posts after all the query args I already set. For some reason it caused a fatal error regarding memory size. I thought maybe it was the syntax, so I changed it to $query->query_vars['search_filter_id'] = 493580; and that seemed to cause endless looping with constant undefined index errors.

    Am I applying it correctly?

    On my WP admin settings, I have the “Display Results” tab set where the method is “As an archive” and the template options are using a custom template, search.php. No slug set and no ajax.

    Thanks.

    dpolonsky
    #207089

    I changed my Display Results tab settings where the method is “custom”, added in the url to my search results which is the WP default http://my-url/search, and I still get a fatal memory error.

    The only difference is I noticed my pre_get_posts function is hooked to add_filter not add_action – should I be using that instead?

    Trevor Moderator
    #207116

    I do not know what might be causing that. The server logs should show you more detail. You could try what you suggest.

    dpolonsky
    #207139

    I’ve undid the settings where I had “custom” set in my “Display Results” tab. So it’s back on archive and set to search.php how I originally had it. My PHP code is back to how I had it as well, minus any S&F hook customizations. However, now the shortcode on search.php is no longer showing the form. When I var dump it, it’s an empty string. Why would the form disappear on the search.php template after changing the “Display Results” settings to “custom” and then back to “archive”? I tried making a new form to see if that was the issue, and the shortcode still no longer outputs the form. 🙁

    dpolonsky
    #207143

    I got the shortcode to show again – nevermind on that part. Still working with getting the post order correct. Will post again if I find any other clues. Thank you for your patience.

    dpolonsky
    #207147

    Ok so I found the issue – or at least what’s really happening. It’s not the orderby or any query args that I set.

    The query for S&F and WP are the same at this point. I even commented out any other pre_get_posts filters I may have had elsewhere in my theme. What happens is for some reason, there are these 5 posts that get put on the top regardless of the search term/order/whatever. So I tried using the WP search with a keyword that had 7 results. I got the same 7 results with the S&F search in the order I wanted, however 5 unrelated posts were on top of them.

    If I change the search term, use the sorting field to change the order, the results change like they’re supposed to, with the exception of those 5 persistent posts on top. It’s the strangest thing – why would that happen?

    I looked up the post IDs for these 5, and they are included in the post__in arg from S&F. I’m not finding any common link between them – they’re different post types. Different categories. I checked the post meta on one to see if there was custom meta from my end, nothing out of the ordinary.

    The results count is correct too, so if there are 7 results, $wp_query->found_posts will be 7. But what displays are those 7, plus those 5 results I can’t seem to get rid of. It’s really baffling.

Viewing 10 posts - 1 through 10 (of 11 total)

The topic ‘Query vars and results order don't match’ is closed to new replies.