-
Notifications
You must be signed in to change notification settings - Fork 9.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Catalog product collection filters produce errors and cause inconsistent behaviour #15187
Comments
@dnsv, thank you for your report. |
What can I do to get rid of the error message? |
Hi @XxXgeoXxX. Thank you for working on this issue.
|
…ause inconsistent behaviour
…ause inconsistent behaviour. Backport of pull request magento#19147
hi @XxXgeoXxX any updates? |
Any updates? this breaks the indexer and causes missing products from the indexed product table. |
Was this ever fixed? Still getting errors in the cron for
|
Any updates? We are having the same issue here with cron
|
Same here on Magento commerce 2.2.8. any updates? |
Same issue I am facing on Magento 2.3.3. I found it in cron.log for indexer_update_all_views. |
So two years later its "ready for dev"? Fixes have already been committed, but the Magento team closed them. This is exactly why Magento is not a trusted product. |
For anyone else with a similar issue. This seems very related to the
|
@ctadlock You mentioned that there are fixes for this. Are we talking about a patch? Do you mind sharing? |
Hi @ctadlock how did you manage to change the MAGE_RUN_TYPE ? |
✅ Jira issue https://jira.corp.magento.com/browse/AC-1026 is successfully created for this GitHub issue. |
✅ Confirmed by @engcom-Hotel. Thank you for verifying the issue. |
For those that want a short term solution/patch, you can edit the following lines in vendor/magento/module-catalog/Model/ResourceModel/Category/Collection.php
|
I'm also having this on 2.4.6, In a certain way, this is linked to #35216 (included in 2.4.7-beta, but not solving anything !) @MatthijsBreed I don't think your fix is safe : when |
@ctadlock I have the same issue on 2.4.6. It would be nice that it does not look at the admin store id... |
Issue is still present on 2.4.7 |
Here are three issues cramped in one, because they are all very similar, are caused by the same model and a possible fix should take all of them into account.
Preconditions
Magento 2.2
The code snippets should be executed in the crontab area, but some problems would likely occur in some other areas too. I've used magento's sample data and n98-magerun's
sys:cron:run
command for easier testing.Issue 1
Steps to reproduce
Expected result
A collection of products that is filtered based on visibility.
Actual result
Details
The code for applying the filters is basically the same as in M1, except the table
catalog_category_product_index
seems to be deprecated in M2 since segmentation for Category Product Indexer was introduced with MAGETWO-89545. Because no store filter is set on the collection, the search is performed on the default store id (0).I'm not quite sure what should the correct result be. M1 produces this select statement:
This select returns no results as the table
catalog_category_product_index
contains only values withstore_id > 0
. The attributevisibility
can be set for scope global, so I'd except the collection to return all products with the given visibility (regardless of how useful a collection filtered by visibility and not by store really is). Or should visibility be applied only when a store is set?Issue 2
Steps to reproduce
Expected result
A collection of products that is filtered based on visibility and store id.
Actual result
Details
This interestingly works if I first set the store filter:
This produces the select statement:
The problem with the visibility filter being set first occurs because the collections limitation filters (function
_applyProductLimitations()
inside\Magento\Catalog\Model\ResourceModel\Product\Collection
) is always applied when a filter function (functionsaddStoreFilter(..)
,addWebsiteFilter(..)
,addCategoryFilter(..)
,addPriceData(..)
,setVisibility(..)
,applyFrontendPriceLimitations()
) is being called.Code walkthrough:
setVisibility(..)
is called on the collection.setVisibility(..)
calls_applyProductLimitations()
._applyProductLimitations()
calls_prepareProductLimitationFilters()
._prepareProductLimitationFilters()
sets thestore_id
product limitation to the default store id (value: 0) and thecategory_id
product limitation to 0.addStoreFilter($storeId)
is called on the collection.addStoreFilter($storeId)
also calls_applyProductLimitations()
which calls_prepareProductLimitationFilters()
. This function should update thecategory_id
product limitation to the default category id for the given store, but this doesn't happen because thecategory_id
product limitation will only get set once, and it was already set in step 4.A possible solution would be to apply the product limitations only before the collection is being loaded - the function
_applyProductLimitations()
should be only called inside the functionload()
and not within every filter function. This would make sure that the filters are being applied when they are all set.Issue 3
Steps to reproduce
Result
The underlying select statement isn't correct. It looks like this:
But should look like this:
Details
Code walkthrough:
addCategoryFilter(..)
is called on the collection. This function checks if the collections store id is equal to\Magento\Store\Model::DEFAULT_STORE_ID
. If it is, the function_applyZeroStoreProductLimitations()
is being called and_applyProductLimitations()
is skipped. This adds the excessINNER JOIN
.addStoreFilter(..)
is called on the collection. Because we've now set a store id that isn't equal to\Magento\Store\Model::DEFAULT_STORE_ID
, the conditions applied by_applyZeroStoreProductLimitations()
are not correct anymore and should be removed (or shouldn't be applied in the first place).The text was updated successfully, but these errors were encountered: