Merged
Conversation
jansentjeu
approved these changes
Mar 6, 2026
|
🎉 This PR is included in version 7.8.1 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pull request fixes two issues with the visibility
Problem 1
Previously, when a child product's visibility was added to a composite product's visibility attribute, it caused unintended behavior if the composite product itself was set to be hidden in either Search or the Catalog.
Example Scenario:
Configurable Parent: Set to "Catalog" visibility, but "Not in Search."
Simple Child: Set to "Search" visibility, but "Not in Catalog."
Current Situation (Before Fix)
When the child's visibility was injected or added to the composite product, the system incorrectly tried to display the composite product in areas where it should have remained hidden (like the Catalog or Search results), or it created conflicts in how Tweakwise filtered the grouped entity. This led to "ghost" products or items appearing in the wrong context because the composite product inherited visibility it should not have had.
Fixed Situation
The logic has been refined to ensure that adding child visibility to a composite product does not break the composite's own visibility restrictions.
The composite product now correctly respects its own "Not Visible Individually" or "Catalog Only" status.
The system now accurately distinguishes between when to show the parent and when to allow the child to drive visibility without "leaking" that visibility back to the parent in an incorrect context.
How to test
The Problem 2 (grouped products)
When using grouped products, child visibility is currently ignored. This causes products to disappear from search results because the system only evaluates the Parent's visibility settings.
Example Scenario:
Configurable Parent: Set to "Catalog" visibility, but "Not in Search."
Simple Child: Set to "Search" visibility, but "Not in Catalog."
Current Situation
In the Catalog: The configurable product is shown, and the simple product is hidden. (Correct)
In Search: The simple product is NOT SHOWN because it is missing from the Tweakwise results. (Incorrect)
This happens because the system switches to "parent visibility" logic, but that logic does not include the child's visibility data. Since the Parent is hidden from Search, Tweakwise excludes the product entirely.
Desired Situation
In the Catalog: The configurable product should be shown, but the simple product should be hidden.
In Search: The simple product should be shown, but the configurable product should be hidden.
How to test
Test test icm with EmicoEcommerce/Magento2Tweakwise#353
Use the how to test in that issue