I'm trying to allow users to sort the search results over at hidden link and have added the sorting shortcode to the page using the View editor but it doesn't seem to have any effect on the actual sorting of the results?
I tried removing it and adding it again in different ways but nothing seemed to work so I'm wondering what I'm doing wrong? Ideally we want the initial ordering to be random but then to allow the users to sort the results by two fields in either ascending or descending order (though if having initial sort as random is problematic we can remove that).
Current code is:
[wpv-sort-orderby type="select" options="field-wpcf-finance-interest-rate,field-wpcf-finance-max-ltcltv" label_for_field-wpcf-finance-interest-rate="Interest Rate" label_for_field-wpcf-finance-max-ltcltv="Maximum LTC/LTV" orderby_as_numeric_for="field-wpcf-finance-interest-rate,field-wpcf-finance-max-ltcltv" orderby_ascending_for="field-wpcf-finance-interest-rate" orderby_descending_for="field-wpcf-finance-max-ltcltv"][wpv-sort-order type="select" options="asc,desc" label_for_asc="Ascending" label_for_desc="Descending" label_asc_for_field-wpcf-finance-interest-rate="Lowest to highest" label_desc_for_field-wpcf-finance-interest-rate="Highest to lowest" label_asc_for_field-wpcf-finance-max-ltcltv="Lowest to highest" label_desc_for_field-wpcf-finance-max-ltcltv="Highest to lowest"]
The other thing is I think it would be neater to move the sorting to above the results rather than as part of the filter/search form which seems to be the only place I can put it? (We've split the form and results into two different blocks). I've attached a screengrab of where the sorting applies now and where I'd like it to move to.
I tried removing it and adding it again in different ways but nothing seemed to work so I'm wondering what I'm doing wrong?
Hi, you may be running into this known issue affecting front-end sorting:
https://toolset.com/errata/front-end-sorting-has-no-effect-if-views-custom-search-and-results-are-displayed-separately-but-on-the-same-page/
The issue in that erratum occurs when the View is "split", so that the filters and results are shown in separate shortcodes or separate widgets. It also requires that the View includes a submit button, and implements a full page reload when the submit button is clicked. At first glance, I think your View matches those requirements, so I'm inclined to believe this is the issue.
One workaround is to use AJAX for the custom search submission. Another workaround is to place the View using a single widget or a single shortcode, rather than splitting it up into separate parts. Use the Output Editor panel in the View editor screen to recreate any special markup structure you were trying to achieve with separate widgets or separate blocks. The filters will be output by the shortcode wpv-filter-meta-html, and the results will be output by the shortcode wpv-layout-meta-html. You can add divs or other markup elements in this panel to recreate a custom structure, for example a two-column Bootstrap grid layout with filters on the left and results on the right, like so:
<div class="row">
<div class="col-4"> <!-- 1/3, left sidebar, for search filters -->
[wpv-filter-meta-html]
</div>
<div class="col-8"> <!-- 2/3, right main area, search results -->
[wpv-layout-meta-html]
</div>
</div>
The other thing is I think it would be neater to move the sorting to above the results rather than as part of the filter/search form which seems to be the only place I can put it?
You can move the sorting controls into the View's Output editor, just before the wpv-loop tags, if you'd like to display those sorting controls just above the results. If your View requires a submit button click, this can be a bit confusing because the search button is so far away from the sorting controls.
Thanks, Christian, handy to know it's a known issue rather than something I'm doing wrong.
I played around with it and managed to get the sorting working using Ajax, the only issue there is that we have some scripting added into the form, one piece to format the numbers with thousand separators as people are typing them in and one to run a calculation based on the value of two of the fields in the form, as well as a "results statement" which updates based on their search params, and none of that stuff runs when ajax is enabled.
Is there a way for me to force these scripts to run on ajax refresh as well as the button submit?
Just checked on the changelog and that issue dates back to Toolset Views 2.7.5 which is around 2 years old, is that right? If so I presume the note on that errata that developers are working to fix ASAP isn't entirely accurate...? 🙂
If it's not going to be fixed then, presuming we have to keep the form submission to using a button in order to ensure our scripts still run, do you think that just not splitting the form and results will work?
Is there a way for me to force these scripts to run on ajax refresh as well as the button submit?
Yes, there are several event hooks available for triggering your own custom JavaScript code at different points in the search and pagination lifecycle. Assuming you are using the legacy Views editor to create this View, you can find a button called "Frontend events" in the Search and Pagination section JS editor panel (screenshot attached).
Click this button to open a popup interface where you can select from the different available event hooks. The system will automatically generate the event hook callbacks and give you some information about the different parameters available in the callback function. For example, if you select the search results updated event, the system will generate an event hook and callback for you like this:
jQuery( document ).on( 'js_event_wpv_parametric_search_results_updated', function( event, data ) {
/**
* data.view_unique_id (string) The View unique ID hash
* data.layout (object) The jQuery object for the View layout wrapper
*/
// Any code you add here will be triggered after the search results have been updated. For example:
console.log('AJAX search results have been updated for View ' + data.view_unique_id);
});
If it's not going to be fixed then, presuming we have to keep the form submission to using a button in order to ensure our scripts still run, do you think that just not splitting the form and results will work?
Not sure I completely follow what you are saying about the button, but yes, I do think that outputting form and results together rather than in separate widgets or with separate shortcodes will solve the problem mentioned in the erratum report. I think it would be prudent to create a test page, insert the consolidated filter/results View, and run a quick test to confirm that expectation.
Thanks Christian, I think for now the best option is just for me to use an integrated rather than split view and keep the submission type as via a submit button as this means not having to rejig the scripting too much, however in due course, with more dev time available from the client, I may return to this.
Thanks for your help - not sure if it's worth bumping the developers to see if they can finally sort the issue of the results not updating when views split given that it's been in the errata for 2 years now?
I hope to see some traction on that outstanding erratum in the round of plugin updates following the upcoming release. From what I understand the upcoming release is focused on WooCommerce issues, and the following round will focus on search improvements. I suspect we will be making progress on that split issue during the general search updates, so I am optimistic about the opportunity for resolution soon. I will keep this ticket updated regarding that release when I have more information to share.
Sounds good to me, thanks Christian.
The fix for this issue is included in the latest round of plugin releases, now available for download or automatic update.