I'm trying to use the product post sorting functionality provided for WooCommerce products (using your [wpv-sort-orderby] and [wpv-sort-order] shortcodes) in a WordPress archive, but after playing around with the sorting options on the frontend, I found that it wasn't actually sorting my posts. I've gotten this to work on other sites before, but the key difference here between my previous implementation and what I'm currently doing is that the design calls for the sorting options to be outside of the filters area, which means I have to put the sorting shortcodes in the Output Editor field editor as opposed to the Search and Pagination field editor.
From what I can tell, the sorting relies on the URL parameters being appended to the current address after refreshing the loop output with AJAX. When I change the sorting option, relevant URL parameters are applied and the loop output refreshes, but the order in which the posts are displayed does not change. This is made even more apparent when I change the sort order from ascending to descending. Once again, no change.
I also attempted to replicate the form markup from the filters area, but that just appeared to make things worse.
Link to a page where the issue can be seen: hidden link
Since I don't have everything styled out yet, for context this is what the design spec is calling for: hidden link
Any help in this matter would be greatly appreciated, thanks!
As an addendum, for testing purposes, I had moved the ordering shortcodes to the Search and Pagination field editor, and I'm still not getting favorable results, so I don't know what I'm doing wrong here.
Hi there,
The sorting options need to be in the "Search and Pagination" section and if it is outside of that the system will not work correctly.
Here is the details on how to implement the sort order feature:
https://toolset.com/documentation/legacy-features/views-plugin/allowing-visitors-to-sort-the-front-end-results/
You will need to use front end styling to move around the pieces in a way that you keep the Sort order in "Search and Pagination" section.
Please check the documentation as ou mentioned even in "Search and Pagination" section it does not work. Make sure you followed all the steps mentioned there and if the issue persists (sort order will not work anywhere out of "Search and Pagination")please get back to us.
Thanks.
I just added the shortcodes in using the selections from the UI elements in the Search and Pagination editor as recommended, and my products are still not being sorted properly (see screenshot-1.png).
Additionally, having the sorting mechanisms restricted to the Search and Pagination editor presents an issue when the design spec calls for the sorting controls to be outside of the filters container (as seen in screenshot-2.jpg). Since there's a hard separation between the filter controls and the loop output, I would be unable to put the sorting controls in a row that is supposed to span over the two columns that contain the filters and the loop output without having to resort to some janky absolute positioning, which I would prefer to not have to do.
This is not the first time I've had a design spec call for this kind of layout (see here: hidden link -- this site is having the same problem, because yeah, the sorting controls are outside the filter container), and yeah I suppose I could tell the designer to not put the sorting mechanisms there in the design, but it MAKES SENSE in the design for them to be there. This is not an uncommon layout design, so why have this restriction in the first place?
Hi there,
Sorry for the late reply.
Regarding the second question, please consider that this is how the system is coded in Toolset and as it is part of the legacy features there will be no change regarding that.
So the shortcodes in question should go to the search and pagination section in the view backend.
But you mentioned that there is a sorting issue happening even if you add the shortcodes inside the search and pagination section which that needs to be checked.
Is it possible that we do changes on the WordPress archive? To test?
I checked my installation and tested and it works with no issues:
hidden link
So if you give us a staging version of the website that we are ok to change things without the fear of ruining anything we can check.
The first thing I would do is to check if there is a plugin conflict:
- IMPORTANT STEP! Create a backup of your website. Or better approach will be to test this on a copy/staging version of the website to avoid any disruption of a live website.
- Switch to the default theme such as "TwentyTwenty" by going to "WordPress Dashboard > Appearance > themes".
- Go to "WordPress Dashboard > Plugins" and deactivate all plugins except Toolset and its add-ons.
- Check if you can still recreate the issue.
- If not, re-activate your plugins one by one and check the issue each time to find out the plugin that causes the problem.
Thanks.
Please feel free to look into this in my staging environment, as this site is still under development. My credentials and backup download are accessible from the first post of this thread.
Hi there,
Thank you. I deactivated all plugins except:
Toolset Types
Toolset Blocks
Toolset Woo Blocks
Woocommerce
Now if you check the sorting works with no issues:
hidden link
This shows that there is a plugin causing the problem.
Please activate the plugins one by one and double-check the sorting to see which one is causing the issue.
Thanks
I discovered what it was. It's because we're using an outdated version of the Toolset WooCommerce Blocks plugin (see attached). With the latest version active, the sorting works (left panel), however if I have 2.9.4 active, the sorting ceases to function (right panel). Full disclosure, I did not activate any other plugins as I noticed you basically had everything disabled aside from the relevant WooCommerce and Toolset plugins.
HOWEVER, there is a reason why we've never updated to WooCommerce Blocks 3.0 and up. As you can see from the screenshot, my Divi Theme Builder global header (and footer) areas break when we attempt to use the latest version (left panel). I have this reported as a known issue which you can defer to here: https://toolset.com/errata/toolset-woocommerce-blocks-3-x-breaks-divi-themer-custom-header-and-footer/#comment-950196
Additionally, here's the original ticket thread where I originally brought this up to support nearly two years ago: https://toolset.com/forums/topic/updating-woocommerce-blocks-breaks-layouts
The reason why we simply don't use Divi's own archive layout functions through their Theme Builder is because it presents way too many limitations, in addition to presenting many issues with Toolset related functions such as conditional logic, especially when compared to the freedom and functionality we get from Toolset archive and shortcode system. The fact that we can mark up the loop items and layout in any way we see fit is a huge boon in and of itself that Divi’s WooCommerce elements can’t afford us. There simply is no comparison.
So this creates an issue for us as we rely heavily on Divi for its ease of use and user friendly builder elements and Toolset for the more complex custom layouts, custom post types, and view/archive functionality that we can't abandon either. I can afford to simply not use the sorting functionality if it came to that, but if we can get a fix for this Divi conflict, that would be most preferable given we'd rather not have to keep using old code in our WooCommerce sites, of which we have built many. I also fully understand that Divi 4.0 is coming at some point which may entirely change how the Theme Builder functions operate, but really that's on you guys for originally advertising support for Divi with Toolset, as we adopted Toolset during that time period when the Toolset Divi Integration plugin existed and have built all of our sites using these two platforms in tandem. So far it has worked wonderfully, and many of the Divi components we use have been largely segregated from major Toolset components that we haven't really run into any major issues aside from this one sticking point.
I appreciate any further insight and/or help in this matter, and if you're able to get this particular issue pushed up to the development team as a priority issue, that would be greatly appreciated.
Hi,
Christopher will be off for a few days, so I'll be following up on this ticket.
I'm going to review and test what's discussed in the ticket and will get back to you, as soon as I can.
Thank you for your patience.
regards,
Waqar
Thank you for waiting.
Based on your comments on the errata page, Nigel already updated our internal ticket on this matter yesterday. He added that the workaround of using older Toolset WooCommerce Blocks affects the sorting functionality.
I see that the internal ticket also had information about your two previous support tickets related to this:
https://toolset.com/forums/topic/layouts-is-creating-a-phpsessid-cookie-that-is-breaking-the-cache-on-our-sites/
https://toolset.com/forums/topic/updating-woocommerce-blocks-breaks-layouts/
We'll keep you updated on the progress through those original tickets; for now, I'm afraid, the only workarounds are those you already know of using the older Toolset WooCommerce Blocks or dropping the sorting functionality.
Thank you, I appreciate it, Waqar.
You're welcome.
We can mark this ticket resolved since we already have the original tickets open.
Feel free to start a new ticket for each new question or concern.
Sounds good. Thank you for looking into this for me.
