The WooCommerce Product Grid Block block is not visible on the front end when the Products block is on the same page.

[gigitux]

Describe the bug

The WooCommerce Product Grid Block block is not visible on the front end when the Products block is on the same page.

This issue is caused by the Compatibility Layer. Probably, the reason is it removes default hooks. We should improve the logic and add the Compatibility Layer only when the WooCommerce Product Grid Block isn't on the page.

With #8507, we are disabling the Compatibility Layer because WC Blocks 9.6.0 will be included in WC Core, but we should on a "real" fix.

To reproduce

Steps to reproduce the behavior:

1. With the Twenty Twenty-Three theme installed, go to Appearance » Editor.
2. Edit the Product Catalog template, adding the Products block above the WooCommerce Product Grid Block.
3. Save.
4. Go to the front end and verify that the WooCommerce Product Grid Block isn't visible.

Expected behavior

WooCommerce Product Grid Block should be visible.

Screenshots

rating.mp4

[gigitux]

The problem is replicable with the Single Product template with #8442.

[dinhtungdu]

I'm sorry for this late reply! But I want to share 2 cents here.

I'm wondering if this is a real bug. Why do merchants want to add the WooCommerce Product Grid block and Products block (which inherit query from the template and are placed before the WooCommerce Product Grid block) on the same page?

I agree that a block shouldn't affect other blocks, but:

• Fixing this issue increases the complexity of our codebase quite a lot.
• The WooCommerce Product Grid block contains the title of the page, which should be placed on top. I can't see the benefit of adding a Products block (that inherits the query) before the page title.

What do you think? I just want to reevaluate my thought process, I'm curious about yours.

[gigitux]

Hey @dinhtungdu, thanks for explaining your point of view!

I don't think the PR adds too much complexity to the codebase. I believe that we should handle these edge cases when possible (and doesn't require a lot of time). Furthermore, even if we postponed the custom inherit query from template option, this code could be useful when we will have this feature and the user wants to create another grid (maybe just a row) with custom filters.

I'm fine with the revert this PR if you think that it isn't necessary :D

[dinhtungdu]

I'm fine with the revert this PR if you think that it isn't necessary :D

I don't think we need to revert the PR. I just want to discuss the POV here 😄

Furthermore, even if we postponed the custom inherit query from template option, this code could be useful when we will have this feature and the user wants to create another grid (maybe just a row) with custom filters.

Can you explain this in more detail? If the compatibility layer breaks pages with multiple Products blocks, we should fix the layer itself IMO.

[Aljullu]

Why do merchants want to add the WooCommerce Product Grid block and Products block (which inherit query from the template and are placed before the WooCommerce Product Grid block) on the same page?

I think there are some legit use cases. A couple that come to my mind:

• Displaying a row of top sellers or products on sale above or below the existing product grid.
• Listing some products in a sidebar (using the Products block), but keep using the WooCommerce Product Grid Block for the main template.

I agree it's kind of an edge case, but I think it's better to have it fixed than keeping it as it was.

[dinhtungdu]

• Displaying a row of top sellers or products on sale above or below the existing product grid.
• Listing some products in a sidebar (using the Products block), but keep using the WooCommerce Product Grid Block for the main template.

@Aljullu If the Products block doesn't have Inherit query from the template enabled, the compatibility layer won't affect the WooCommerce Product Grid block. In other words, I can't find a use case where merchants want to add both WooCommerce Product Grid and Products blocks which all show the products from the main query.

[Aljullu]

Oh, sorry, I missed that. In that case, I agree, it doesn't seem like a use case that might be useful right now. 🤔

[gigitux]

I'm fine with the revert this PR if you think that it isn't necessary :D

I don't think we need to revert the PR. I just want to discuss the POV here 😄

Furthermore, even if we postponed the custom inherit query from template option, this code could be useful when we will have this feature and the user wants to create another grid (maybe just a row) with custom filters.

Can you explain this in more detail? If the compatibility layer breaks pages with multiple Products blocks, we should fix the layer itself IMO.

I was referring to the use case that @Aljullu described above, so WooCommerce Product Grid along with the Products block with Inherit query from the template enabled with filters, but it is a future thing.

I'm thinking about it, but this PR is still necessary for the Single Product Template. With the Products block by a flag, you disabled/enabled the compatibility layer. On the Single Product Template, this is not possible. So the compatibility layer is always loaded. Without this PR, the WooCommerce Product Grid will not work anymore on the Single Product template because the layer will be always loaded and the default hooks replaced. So, it is necessary to find a way to disable the layer when the WooCommerce Product Grid is used: does it make sense?