From 8020145096fc8caaee91c352a3ff86664ae46718 Mon Sep 17 00:00:00 2001 From: Audrius Date: Sat, 27 Jun 2026 03:35:58 +0200 Subject: [PATCH] Fix price indexation loop stopping early with non-sequential product ids indexPrices() used $cursor (the last indexed id_product returned by indexPricesUnbreakable()) as the do/while continuation check against $nbProducts (the number of products to index). Since product ids are not necessarily sequential and are commonly larger than the product count (gaps left by deleted, imported or migrated products), $cursor < $nbProducts becomes false as soon as an indexed id exceeds the count, so the batching loop stops after very few iterations and the work falls back to one 100-row batch per recursion/AJAX call. On large catalogues this both slows full indexation dramatically and deepens the indexPrices() self-recursion. Compare the real progress counter instead. --- ps_facetedsearch.php | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/ps_facetedsearch.php b/ps_facetedsearch.php index 5cf2cd86f..c3b29b004 100644 --- a/ps_facetedsearch.php +++ b/ps_facetedsearch.php @@ -1583,7 +1583,11 @@ private function indexPrices($cursor = 0, $full = false, $ajax = false, $smart = $time_elapsed = microtime(true) - $startTime; $indexedProducts += $length; } while ( - $cursor < $nbProducts + // $cursor is the last indexed id_product (returned by indexPricesUnbreakable()), not a + // counter, so comparing it to the product count is wrong: with non-sequential ids (gaps + // from deleted/imported products) it stops batching as soon as an id exceeds $nbProducts. + // Track how many products were actually indexed instead. + $indexedProducts < $nbProducts && (Tools::getMemoryLimit() == -1 || Tools::getMemoryLimit() > memory_get_peak_usage()) && $time_elapsed < $maxExecutiontime );