If PrestaShop puts products in the wrong order when you select “lowest price first”, compare the price shown to the customer with the data used for sorting. In a store using Faceted Search, promotions, the price index and customer context can all matter. Clearing the cache alone does not explain why the problem returns.
Why can the correct price appear in the wrong position?
Suppose product A originally cost PLN 79 and now costs PLN 49 after a discount. Product B costs PLN 59. In ascending order, A should appear before B. If the listing uses the outdated value of PLN 79, the order will be reversed even though the product card correctly shows PLN 49. This illustrates the mechanism; these are not figures from a particular store.
A price index is a supporting dataset that a module uses to filter and sort the catalogue. Its freshness must be checked separately from the price displayed on the page. A cache holds a previously prepared result or piece of content. Clearing the cache and rebuilding the index are different operations, even when both happen during the same deployment. You can trace the indexing mechanism in the ps_facetedsearch module source code.
A price also depends on purchasing conditions: the shop in a multistore setup, currency, country, tax, customer group or selected combination. Sorting must therefore be assessed against the price the user sees in the scenario being tested. An official issue about sorting and customer-group prices illustrates how a mismatch between an indexed value and the price for a particular customer can disrupt the order. Similar symptoms do not always have the same cause.
A case from our work: promotions and a stale index
In one store we support, price sorting became incorrect following changes to promotions. We investigated Faceted Search and the way its index was refreshed. The change covered refreshing data when a promotional price was added, edited or deleted, as well as handling changes triggered by promotion dates.
The deployment also required running the module upgrade to register the mechanisms invoked when data changes. We then rebuilt the price index and cleared the relevant cache layers. Copying the files alone did not complete the procedure.
On production, we checked 251 products in one category across 21 pages. Verification covered ascending and descending sorting, including transitions between pages. We compared the current promotional prices shown to customers rather than the crossed-out original prices. No ordering errors occurred during that check.
This confirmed that current sorting was correct after deployment and rebuilding the index. A separate, controlled test crossing a promotion’s start or end date remained outstanding. Checking the current listing is not the same as confirming every future pricing scenario.
How to investigate incorrect price sorting
- Record the reproduction conditions. The category, sorting direction, page number, currency and login status make it possible to compare the same result before and after the fix.
- Identify a specific pair of products. Record their current prices and expected order. “Sorting does not work” provides too little detail to establish the cause.
- Identify what generates the listing. Check the filtering module, search provider, custom changes and their compatibility with the store’s PrestaShop version.
- Compare the promotion with the index. Has the discount been saved while the index still holds the previous price? Does it apply to everyone or only one customer group?
- Check how refreshes happen. Creating, editing, deleting and expiring a promotion are separate events. The passage of time is different from manually saving a product.
- Verify the complete result. A correct first page does not rule out a problem at a page boundary or in the other sorting direction.
What should testing after the fix cover?
Include a product without a promotion, a discount that has been added and changed, a deleted promotion, and one with a start and end date. A store with several currencies, customer groups or shops also needs the relevant combinations of those conditions. The scope depends on the store’s configuration. Checking prices as an administrator does not establish that every customer sees the same result.
Compare the order across consecutive pages, product counts and displayed prices. After rebuilding the index, confirm that the job completed rather than merely started. For older installations, the repair plan must account for module compatibility: upgrading directly to the newest available release is not always possible.
Frequently asked questions
Is clearing the cache enough?
It can help when a cached listing is the problem. If the stale data is in the price index, that index needs refreshing, and you need to establish why it was not updated when the promotion changed.
Should the whole index be rebuilt after every promotion?
Data should ultimately be refreshed in a way appropriate to the module and configuration. A manual full rebuild can be a repair step, but updates for individual products and scheduled promotions also need checking.
Need someone to check your store?
If products stopped sorting correctly after a promotion, update or module change, contact Projectic. Send the category URL, two example products and the conditions in which the error occurs. That gives us a useful starting point for diagnosis and defining the work. You can also explore our PrestaShop projects.