UPSTREAM FIX
magento2-36900: Category pages showing the oldest products first, with a new sort config
Community fix magento2-36900 merged into magento/magento2 on 2025-11-19, released in 2.4.9; applies cleanly to 6 releases from 2.4.8 to 2.4.8-p5.
Fixes category pages showing the oldest products first, with a new sort config edited
- Pull request title
- Elastic Search interferes with the default sort order of products (changing newest first to oldest first)
- Pull request
- magento/magento2#36900
- Issues
- #31043 human
- Author
- @rogerdz
- Merged
- 2025-11-19
- Fixed in
- 2.4.9
- Reported on
- 2.3.5-p1
- Categories
- Catalog/Product
- Components
- magento/module-catalog, magento/module-catalog-search
Labels
- Area
- Catalog
- Component
- Catalog
- Priority
- P2
- Severity
- —
- Reported on (labels)
- 2.3.5-p1
Issue
Title and steps come from the upstream issue and pull request.
Description
1. The oldest products(with the lower entity_id) are shown first
2. The Order by for the SQL query for retrieving the products
2. The Order by for the SQL query for retrieving the products
SELECT `e`.*, `price_index`.`price`, `price_index`.`tax_class_id`, `price_index`.`final_price`, IF(price_index.tier_price IS NOT NULL, LEAST(price_index.min_price, price_index.tier_price), price_index.min_price) AS `minimal_price`, `price_index`.`min_price`, `price_index`.`max_price`, `price_index`.`tier_price`, IFNULL(review_summary.reviews_count, 0) AS `reviews_count`, IFNULL(review_summary.rating_summary, 0) AS `rating_summary`, `stock_status_index`.`stock_status` AS `is_salable` FROM `catalog_product_entity` AS `e` INNER JOIN `catalog_product_index_price` AS `price_index` ON price_index.entity_id = e.entity_id AND price_index.customer_group_id = 0 AND price_index.website_id = '1' LEFT JOIN `review_entity_summary` AS `review_summary` ON e.entity_id = review_summary.entity_pk_value AND review_summary.store_id = 1 AND review_summary.entity_type = (SELECT `review_entity`.`entity_id` FROM `review_entity` WHERE (entity_code = 'product')) INNER JOIN `cataloginventory_stock_status` AS `stock_status_index` ON e.entity_id = stock_status_index.product_id AND stock_status_index.website_id = 0 AND stock_status_index.stock_id = 1 WHERE (stock_status_index.stock_status = 1) AND (e.entity_id IN (1201, 1202, 1203)) ORDER BY FIELD(e.entity_id,1201,1202,1203)
Steps to reproduce
- Create a category in Magento with several products in it, all have the position in the category set to the value 1
- Go to category page
- Go to category page
Expected result
1. The newest products in the database (the one with the highest entity_id) are shown first
2. The Order by for the SQL query for retrieving the products
2. The Order by for the SQL query for retrieving the products
SELECT `e`.*, `cat_index`.`position` AS `cat_index_position`, `price_index`.`price`, `price_index`.`tax_class_id`, `price_index`.`final_price`, IF(price_index.tier_price IS NOT NULL, LEAST(price_index.min_price, price_index.tier_price), price_index.min_price) AS `minimal_price`, `price_index`.`min_price`, `price_index`.`max_price`, `price_index`.`tier_price` FROM `catalog_product_entity` AS `e` INNER JOIN `catalog_category_product_index_store1` AS `cat_index` ON cat_index.product_id=e.entity_id AND cat_index.store_id=1 AND cat_index.visibility IN(2, 4) AND cat_index.category_id=33 INNER JOIN `catalog_product_index_price` AS `price_index` ON price_index.entity_id = e.entity_id AND price_index.customer_group_id = 0 AND price_index.website_id = '1' ORDER BY `cat_index`.`position` asc, `e`.`entity_id` DESC
Actual result
1. The oldest products(with the lower entity_id) are shown first
2. The Order by for the SQL query for retrieving the products
---
Please provide [Severity](https://devdocs.magento.com/guides/v2.3/contributor-guide/contributing.html#backlog) assessment for the Issue as Reporter. This information will help during Confirmation and Issue triage processes.
- [ ] Severity: S0 _- Affects critical data or functionality and leaves users without workaround._
- [ ] Severity: S1 _- Affects critical data or functionality and forces users to employ a workaround._
- [ ] Severity: S2 _- Affects non-critical data or functionality and forces users to employ a workaround._
- [ ] Severity: S3 _- Affects non-critical data or functionality and does not force users to employ a workaround._
- [ ] Severity: S4 _- Affects aesthetics, professional look and feel, “quality” or “usability”._
The severity of this issue will differ between niches but for some businesses, this is quite critical. Like designer or boutique fashion retailers where the target audience frequent the website to view the latest items to hit the fashion lines etc.
---
I can't believe there are not more reports of this... I did [ask the question](https://magento.stackexchange.com/questions/326729/elastic-search-v7-changing-magento-default-product-sort-position-in-categories) on Magento Stack Exchange and it is passed by will hardly any views and zero interaction.
I'm obviously assuming this is a bug and not meant to happen.
2. The Order by for the SQL query for retrieving the products
SELECT `e`.*, `price_index`.`price`, `price_index`.`tax_class_id`, `price_index`.`final_price`, IF(price_index.tier_price IS NOT NULL, LEAST(price_index.min_price, price_index.tier_price), price_index.min_price) AS `minimal_price`, `price_index`.`min_price`, `price_index`.`max_price`, `price_index`.`tier_price`, IFNULL(review_summary.reviews_count, 0) AS `reviews_count`, IFNULL(review_summary.rating_summary, 0) AS `rating_summary`, `stock_status_index`.`stock_status` AS `is_salable` FROM `catalog_product_entity` AS `e` INNER JOIN `catalog_product_index_price` AS `price_index` ON price_index.entity_id = e.entity_id AND price_index.customer_group_id = 0 AND price_index.website_id = '1' LEFT JOIN `review_entity_summary` AS `review_summary` ON e.entity_id = review_summary.entity_pk_value AND review_summary.store_id = 1 AND review_summary.entity_type = (SELECT `review_entity`.`entity_id` FROM `review_entity` WHERE (entity_code = 'product')) INNER JOIN `cataloginventory_stock_status` AS `stock_status_index` ON e.entity_id = stock_status_index.product_id AND stock_status_index.website_id = 0 AND stock_status_index.stock_id = 1 WHERE (stock_status_index.stock_status = 1) AND (e.entity_id IN (1201, 1202, 1203)) ORDER BY FIELD(e.entity_id,1201,1202,1203):warning: Note: In Magento 2.3.6 with
Search Engine=MySQL the newest product in the database (the one with the highest entity_id) was shown first. With Magento 2.4-develop with Search Engine= Elasticsearch 7 this behaviour changed. The oldest product is shown first, the newest last.---
Please provide [Severity](https://devdocs.magento.com/guides/v2.3/contributor-guide/contributing.html#backlog) assessment for the Issue as Reporter. This information will help during Confirmation and Issue triage processes.
- [ ] Severity: S0 _- Affects critical data or functionality and leaves users without workaround._
- [ ] Severity: S1 _- Affects critical data or functionality and forces users to employ a workaround._
- [ ] Severity: S2 _- Affects non-critical data or functionality and forces users to employ a workaround._
- [ ] Severity: S3 _- Affects non-critical data or functionality and does not force users to employ a workaround._
- [ ] Severity: S4 _- Affects aesthetics, professional look and feel, “quality” or “usability”._
The severity of this issue will differ between niches but for some businesses, this is quite critical. Like designer or boutique fashion retailers where the target audience frequent the website to view the latest items to hit the fashion lines etc.
---
I can't believe there are not more reports of this... I did [ask the question](https://magento.stackexchange.com/questions/326729/elastic-search-v7-changing-magento-default-product-sort-position-in-categories) on Magento Stack Exchange and it is passed by will hardly any views and zero interaction.
I'm obviously assuming this is a bug and not meant to happen.
Taken from the upstream issue.
Code match per tag
Each tag was checked with git apply --check against that tag's files. A clean match means the change applies; it is not a test result. Tags that already contain the fix are marked.
| Line | Code match per tag | Tests |
|---|---|---|
| 2.4.6 | 2.4.6 conflict 2.4.6-p1 conflict 2.4.6-p2 conflict 2.4.6-p3 conflict 2.4.6-p4 conflict 2.4.6-p5 conflict 2.4.6-p6 conflict 2.4.6-p7 conflict 2.4.6-p8 conflict 2.4.6-p9 conflict 2.4.6-p10 conflict 2.4.6-p11 conflict 2.4.6-p12 conflict 2.4.6-p13 conflict 2.4.6-p14 conflict 2.4.6-p15 conflict | 2.4.6: no test data 2.4.6-p1: no test data 2.4.6-p2: no test data 2.4.6-p3: no test data 2.4.6-p4: no test data 2.4.6-p5: no test data 2.4.6-p6: no test data 2.4.6-p7: no test data 2.4.6-p8: no test data 2.4.6-p9: no test data 2.4.6-p10: no test data 2.4.6-p11: no test data 2.4.6-p12: no test data 2.4.6-p13: no test data 2.4.6-p14: no test data 2.4.6-p15: no test data |
| 2.4.7 | 2.4.7 conflict 2.4.7-p1 conflict 2.4.7-p2 conflict 2.4.7-p3 conflict 2.4.7-p4 conflict 2.4.7-p5 conflict 2.4.7-p6 conflict 2.4.7-p7 conflict 2.4.7-p8 conflict 2.4.7-p9 conflict 2.4.7-p10 conflict | 2.4.7: no test data 2.4.7-p1: no test data 2.4.7-p2: no test data 2.4.7-p3: no test data 2.4.7-p4: no test data 2.4.7-p5: no test data 2.4.7-p6: no test data 2.4.7-p7: no test data 2.4.7-p8: no test data 2.4.7-p9: no test data 2.4.7-p10: no test data |
| 2.4.8 | 2.4.8 clean 2.4.8-p1 clean 2.4.8-p2 clean 2.4.8-p3 clean 2.4.8-p4 clean 2.4.8-p5 clean | 2.4.8: no test data 2.4.8-p1: no test data 2.4.8-p2: no test data 2.4.8-p3: no test data 2.4.8-p4: no test data 2.4.8-p5: no test data |
| 2.4.9 | 2.4.9 conflictcontains the fix | 2.4.9: no test data |
Triage
Model @cf/cloudflare/clef. Probability this is a bug fix: 93.4%. Probability it is security relevant: 0.7%.
Show the model's answers and probabilities
| Question | Answer | Probabilities | Confidence |
|---|---|---|---|
| Change kind | bugfix | bugfix 84.3%, feature 12.8%, refactor 1.7%, tests_only 0.8%, dependency 0.3%, docs_only 0.2% | 67.2% |
| Area | catalog | catalog 79.0%, admin 11.0%, frontend 3.0% | 58.7% |
| Reported version | unspecified | unspecified 38.0%, 2.4.2-p2 3.1%, 2.4.3-p1 3.0% | 14.1% |
| Scope | 1.49 of 2 | 2 64.0%, 1 21.2%, 0 14.8% | 21.4% |
| Risk | 0.77 of 2 | 1 42.5%, 0 40.5%, 2 17.0% | 6.0% |
| Worth backporting | 1.41 of 2 | 2 57.0%, 1 27.6%, 0 15.5% | 13.7% |
Download
For cweagans/composer-patches, choose a version below and download the bundle. Copy its magento2-36900/ folder into patches/composer/, merge composer.patches.json into composer.json, then run composer install. Test files are always removed; paths are relative to each package root, using the default -p1 level.
Bundle README (what the ZIP ships)
# magento2-36900 Community fix merged upstream into magento/magento2, adapted by magento.watch. This is not a patch published by Adobe. Pull request: https://github.com/magento/magento2/pull/36900 Issue: https://github.com/magento/magento2/issues/31043 Author: @rogerdz Source commit: 343d04a260998ed35546f0f399dabd19e0d991bb Modifications: test files and documentation removed, paths rewritten relative to each Composer package. Licence: OSL-3.0 / AFL-3.0, as the original Magento Open Source code. Maintainer: Łukasz Bajsarowicz (@lbajsarowicz)
Licence: Magento Open Source code under OSL-3.0 and AFL-3.0. The bundle carries the original author, source commit and the list of modifications.
