[Resuelto] Unable to Properly Sort WooCommerce Products by Dynamic Price
Este hilo está resuelto. Aquí tiene una descripción del problema y la solución.
Problem: I am using the Dynamic Pricing plugin to show different prices to different Users. When I use WooCommerce Views to display a View of Products sorted by price, the sort order doesn't seem to be working correctly.
Solution: WooCommerce Views sort by price feature won't work well with Dynamic Pricing, because only one price is supported per product. Remember to recalculate static values in WooCommerce Views whenever settings that affect price are modified, otherwise sorting by price may not be accurate according to the displayed price.
This support ticket is created hace 5 años, 10 meses. There's a good chance that you are reading advice that it now obsolete.
This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.
Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.
Hoy no hay técnicos de soporte disponibles en el foro Juego de herramientas. Siéntase libre de enviar sus tiques y les daremos trámite tan pronto como estemos disponibles en línea. Gracias por su comprensión.
I am trying to allow users to sort WooCommerce products by their prices. From least to greatest (asc) or greatest to least (desc).
Link to a page where the issue can be seen:
Without sorting filters: enlace oculto
With sorting filters: enlace oculto enlace oculto
I expected to see my products to be sorted properly by their assigned prices.
Instead, I got:
With the wpv_sort_orderby value set to "field-views_woo_price" (the option provided in the sorting options dialog) the grand majority of my products are removed from the view's results output.
With the wpv_sort_orderby value set to "wpv-views_woo_price" (another URL parameter filter I'm using with a different filter) the results have a changed order, but they don't appear to have a discernible logic. They're certainly not being sorted by their price. All products display in the view output, however.
So here's my setup: I've created a sorting form from html, utilizing the same URL parameters generated from the views sorting options filters shortcode, which I have stuffed away in a content template, so that changes are mirrored to the category specific archive.
The other two sorting filters, sort by post title & sort by post date, work just fine along with the accompanying ascending/descending value, but when I opt to sort by price, my results do not appear as they should.
In addition to that, I was wondering if there was a way retain existing search filters if this form is submitted. For example, if someone selects a taxonomy term or price range filter from the left, and then they sort that output by their price or post date, I'd like the sorting action to sort only the values that were generated with the first set of filters.
It's a sorting control, but it's hidden. This tells the View that it needs to respect the sorting URL parameters you've got set up.
For example, if someone selects a taxonomy term or price range filter from the left, and then they sort that output by their price or post date, I'd like the sorting action to sort only the values that were generated with the first set of filters.
Not sure I follow, can you check the current functionality and let me know if it's working correctly now? If not, I'll take a closer look.
Ok, great. That's working. I had modify my form a little bit to output the URL parameter "wpv_sort_orderby_as" with a value as "numeric" to get it to sort appropriately. It seems all the products are displaying in the loop output.
Now for my second question. I'm sorry if I wasn't clear enough. If you select some filter options in the left sidebar and select submit, it outputs a filtered value in the loop output. But what if the user then decides that they want to sort those results by their price, as the current default sorting is alphabetized by post title?
With the way it's currently setup, the sorting form clears out any existing filtered results (and vice versa) if you select sorting options from those inputs. From what I can gather, it overrides the previously generated URL parameters, and replaces them with its own.
For example, if you select the Power Units & Parts, then select Submit, the URL will output as follows: enlace oculto
But if you select a sorting filter from "Sort by:", such as Product Price and Ascending, the URL will output like this: enlace oculto
I don't quite know how to retain the existing URL parameters, and override the necessary ones to change the sorting order.
There's nothing built-in to help you do that. You'll have to use custom JavaScript to inspect the current URL parameters, then modify them as needed and adjust your custom form submission URL on-the-fly. It'll be tricky. https://html-online.com/articles/get-url-parameters-javascript/
Looks like I'm not out of the woods yet. After entering some more final pricing, I started noticing that it still wasn't properly sorting the products, as made evidenced by my screenshot.
My URL parameter output is as follows: enlace oculto
It should be noted that I'm using WooCommerce's dynamic pricing plugin, with different prices being assigned to logged in users. This would be fine if it was referring to the original prices, but it's not even doing that. And if I'm logged out, it still doesn't sort the products properly.
It should be noted that I'm using WooCommerce's dynamic pricing plugin, with different prices being assigned to logged in users.
I see. Unfortunately WooCommerce View's calculated price value doesn't support different prices for different Users. One static price is calculated for all Users and stored for quick reference as a custom field, whenever the "Static Product Fields for Parametric Searches" task is run (Toolset > WooCommerce Views > Static Product Fields for Parametric Searches).
This is why the products appear out of order in a View sorted by price. Example screenshot here is from the product "10 Liter Black Tank", which is shown as $59 to a logged-out User but is calculated as 29.6 for everyone. Sorting uses that 29.6 value, even though the displayed price is $59. The static price can be seen in the Product editor screen in wp-admin. Twirl open the WooCommerce Views Filter Fields section and you can see the single calculated value. This value is used for parametric searches, not a price specific to the current logged-in User. To do that, you would need custom code that interacts with the query parameters and filters to sort based on the current User's price, which is either calculated on-the-fly by the dynamic pricing plugin, or pulled from the database somehow. This type of customization falls outside the scope of support we provide here, and I don't have a cut-and-paste code snippet to handle that query modification. We do have some basic query filtering examples available here: https://toolset.com/documentation/programmer-reference/views-filters/#wpv_filter_query
I can understand and respect that, but if I disable the Dynamic Prices plugin, the products are still not sorted properly. Does that make it within scope, now? At the very least, I'd expect the core price to be respected by the sorting filters, regardless what is populated for the Dynamic Price plugin.
Again, the sort algorithm is based on static price values that are calculated by WooCommerce Views and stored as custom field values. The sort algorithm is not based directly on the actual WooCommerce price. This helps speed up searches and sorting in Views. The calculation process that sets those custom field values is managed in Toolset > WooCommerce Views, and it's currently configured to be triggered manually (see attachment). When I checked just now, the last calculation process was run yesterday, so I'm guessing the static prices were not calculated since you disabled the Dynamic pricing plugin. The static custom field price was still set at the old dynamic price for Admins, even though the WooCommerce price had already been updated. I ran the calculation process again manually, and now the price sort looks accurate. I would consider setting that calculation process to run on some regular interval with the WordPress cron, so you don't have to remember to trigger it manually whenever prices are modified somehow.