Describe the bug

Seems that somebody used add_filter to handle action like code, but didn't return anything, so filtering before WooCommerce results in corrupted values.

Add filter & callback. This is done in 2 different files in that directory.

The other file is RelatedProducts.php

Impact on pre_render_block in this way means that if you returned '' (to remove a block), at priority 9 or 10 , WooCommerce's filters will void that out by not returning anything.

Hook in at 11 and the issue is gone (for us).

But I know we aren't the only plugin using that filter, so this is likely mucking up other things without any real indication its happening.

I should add this only occurs on WooCommerce pages.

To reproduce

Steps to reproduce the behavior:

1. Create woocommerce my account page.
2. Either use our plugin Content Control to add rules to a block (Show to logged out users only makes for easy test), or manually filter pre_render_block at priority 9 and return '' for any block to remove it from the page.
3. The block will still appear on woocommerce pages, but not on others.

Expected behavior

These 2 callbacks should at minimum return $pre_render;, and should ideally be optimized to bail early in cases where $pre_render is set but to empty-ish values.

If the item was removed from page, no need to run additional checks for loading assets etc.

Environment

WordPress (please complete the following information):

• WordPress version: 6.3.1
• Gutenberg version (if installed): Latest
• WooCommerce version: 8.1.1
• WooCommerce Blocks version: bundled with WooCommerce 8.1.1
• Site language:
• Any other plugins installed: Content Control