We´re trying to allow changing the sort order of search results with pagination set to infinite scrolling.
In the search form, sort options are displayed, but it´s not possible to choose another option.
So we wonder if that might be impossible in infinite scroll views?
THANK YOU 🙂
Hi, yes it should be possible to change the sort order of search results with infinite scrolling. Is this search View created using the Block Editor or the legacy Views editor? Can you show me screenshots of the sorting control configurations (if you're using the Block Editor) or copy + paste the shortcodes used to display sorting controls in the legacy editor, and screenshots of the pagination settings?
When you say it is not possible to choose another option, are you saying the sorting controls are inactive and cannot be changed, or they can be changed but the sort order does not seem to be updating as expected? Can I see this on the front-end of your site somewhere? Please provide a URL if so.
Hi 🙂
It´s created by legacy editor:
[wpv-sort-orderby type="radio" options="field-mrp_rating_result_1_star_rating,field-wpcf-med-datum" label_for_field-mrp_rating_result_1_star_rating="Bewertung" label_for_field-wpcf-med-datum="Veranstaltungsdatum" orderby_as_numeric_for="field-wpcf-med-datum" orderby_ascending_for="field-wpcf-med-datum" orderby_descending_for="field-mrp_rating_result_1_star_rating"]
It´s not possible to ativate the radio box of the second sort option.
THANK YOU 🙂
Okay thank you for the additional information. I do not see anything obviously wrong in your screenshots or in the sorting control shortcode. Can you try these troubleshootings steps next?
- Temporarily deactivate all plugins except Types and Views (or Blocks). Temporarily activate a default them like Twenty Twenty One. Temporarily deactivate all custom code snippets in Toolset > Settings > Custom Code. Temporarily delete or disable any custom JavaScript code you have applied to this View.
- Test again. If the problem is resolved, reactivate components one by one, testing each time, until the problem returns. Let me know if there is one specific component causing this conflict.
- Edit the View and temporarily choose the option "Always show all values for inputs" if it is not already selected in the Custom Search Settings panel. You must first choose "Let me choose individual settings manually" to select this option. See the screenshot custom-search-manual.png for a visual guide. If the Custom Search Settings section is not visible in the View editor screen, scroll to the top right corner of the screen and click "Screen Options". You can enable the Custom Search Settings section here.
- Change the order of the sorting options so that the option field-wpcf-med-datum should be displayed first:
[wpv-sort-orderby type="radio" options="field-wpcf-med-datum,field-mrp_rating_result_1_star_rating" label_for_field-mrp_rating_result_1_star_rating="Bewertung" label_for_field-wpcf-med-datum="Veranstaltungsdatum" orderby_as_numeric_for="field-wpcf-med-datum" orderby_ascending_for="field-wpcf-med-datum" orderby_descending_for="field-mrp_rating_result_1_star_rating"]
- Are both options enabled now?
- Temporarily replace the options with standard fields like date and title:
[wpv-sort-orderby type="radio" options="post_date,post_title" label_for_post_date="Post date" label_for_post_title="Post title" orderby_ascending_for="post_title" orderby_descending_for="post_date"]
- Are both options enabled now?
Shit!
This seems to be a theme-related problem.
Yes, it´s quite old, but we never found the time to switch to another one...
This day was to come...
Or do you perhaps see any chance to get around with that old inkblot-theme?
Is there anything typical one could do here to prevent theme-switch?
THANK YOU 🙂
Or do you perhaps see any chance to get around with that old inkblot-theme?
I'm not sure offhand, I would need to see the problem in the browser to understand more about what is happening here. Can you provide a URL and step-by-step instructions to see the problem? Any URL you share here in the forum will be hidden from public view.
Is there anything typical one could do here to prevent theme-switch?
If you provide a URL I will take a closer look at the problem to see if this is a bug, or if there is something else that can be done to work around the issue. If it's a compatibility issue or conflict with Toolset and the theme, I can submit a ticket for our compatibility team to take a closer look. Unfortunately that's not usually a quick fix. It takes time and often involves collaboration with the theme developers. If there was a time when this feature functioned as expected, another option to consider is reverting to older versions of the theme and/or Toolset plugins. Alternatively, if your WordPress installation, theme, and Toolset pluign suite are not currently up-to-date, consider updating those to the latest versions.
hidden link
Below you see where the sort option should be changed. (top-left corner of the screen)
THANK YOU 🙂
I spent some time investigating this today and I am pretty sure this is not a theme issue. I think the problem is on the Toolset side. The reason you only see the problem when your theme is active is because the problem only appears when the same View is inserted multiple times on the page. In your case, the main search View is inserted once in the mobile menu, which is displayed in one of your site widgets. That widget is theme-specific, so when you select a different theme this widget is not included in the page, so the problem is not reproduced.
In my local tests, I am able to replicate this issue where the sorting direction radio button cannot be selected when I have the same custom search View filters included in a page twice using this general format:
<div>[wpv-form-view name="books" target_id="self"]</div>
<div>[wpv-form-view name="books" target_id="self"]</div>
[wpv-view name="books" view_display="layout"]
You have something similar now on your site. The custom search filters are included once in the mobile menu, then again in the main sidebar. I need to do a bit more investigation, then I can escalate this to my 2nd tier support team. Please stand by and I will give you an update tomorrow, as my shift has ended here today.
Okay after some more tests confirming what I found yesterday, I have escalated this issue to my 2nd tier team for additional investigation. It seems that sorting controls displayed as radio inputs are not working correctly when the filters for a View are included multiple times on the same page. Only the first set of radio inputs can be changed effectively.
One workaround I found in my local testing is to change the type of sorting control inputs from type="radio" to type="select" or type="list" in the wpv-sort-orderby shortcode. These alternative input types do not have the same problem, and sorting seems to work as expected in my local tests. Example of the "select" control type:
[wpv-sort-orderby type="select" options="field-mrp_rating_result_1_star_rating,field-wpcf-med-datum" label_for_field-mrp_rating_result_1_star_rating="Bewertung" label_for_field-wpcf-med-datum="Veranstaltungsdatum" orderby_as_numeric_for="field-wpcf-med-datum" orderby_ascending_for="field-wpcf-med-datum" orderby_descending_for="field-mrp_rating_result_1_star_rating"]
Great ! THANK YOU so far 🙂
Now with your help, I found a solution to our problem: Somehow the sort order of the search results is controlled by the mobile menu.
So by manipulating the mobile menu by jquery, it kind of works (search results seem to be loaded twice, though).
So now we can do what we intend.
However, I don´t close this thread for now, anxiously waiting for further results on this...
Now, this doesn´t work any more...
Yes, sorting with radio inputs is definitely not working well and I do not expect that manipulating the controls with JavaScript will be completely effective. Are you saying that sorting is also broken when you change to type="select" or type="list"?
I have escalated the radio inputs problem to my 2nd tier support team and will keep you updated here as I receive more information.
Our 2nd tier support team has escalated the radio input issue to the developers for resolution. If a workaround or patch becomes available, I will give you that infomation in an update here.