NO BUG: Query loop with post_type=product returns no results after upgrading to Bricks 2.3

Bugs
1

Bug: Query loop with post_type=product returns no results after upgrading to Bricks 2.3

I’ve identified the root cause of this bug through Query Monitor analysis and database inspection.

Summary

After upgrading to Bricks 2.3, any query loop with post_type=product returns zero results. The SQL generated contains AND ( 0 = 1 ), which always returns an empty result set. Rolling back to Bricks 2.2 fixes the issue immediately.

Root cause — 3 points

1. New productType control introduced in 2.3 but not visible in the UI

includes/woocommerce/helpers.php defines a new productType control:

php

'productType' => [
    'tab'         => 'content',
    'label'       => esc_html__( 'Product type', 'bricks' ),
    'type'        => 'select',
    'options'     => wc_get_product_types(),
    'multiple'    => true,
    'placeholder' => esc_html__( 'Select product type', 'bricks' ),
],

This control is not rendered in the builder UI — it does not appear in the query panel. Users cannot see it, set it, or clear it.

2. The value ['all'] is automatically written to the database

Existing query loop elements received productType: ['all'] in their database settings after upgrading to 2.3 — not set by the user, as the control is invisible. Confirmed directly in the database:

s:11:"productType";a:1:{i:0;s:3:"all";}

3. all is not a valid WooCommerce product type term

At line 360, Bricks builds a tax_query using this value:

php

if ( ! empty( $settings['productType'] ) ) {
    $tax_query['product_type'] = [
        'taxonomy' => 'product_type',
        'field'    => 'slug',
        'terms'    => $settings['productType'], // ['all']
    ];
}

Valid WooCommerce terms for product_type taxonomy are: simple, variable, grouped, external. The term all does not exist. WP_Tax_Query cannot resolve it and converts the entire query to 0 = 1:

sql

WHERE 1=1 AND ( 0 = 1 ) AND wp_posts.post_type = 'product'

Fix

Either skip the tax_query when all is selected, or — since the UI control is not yet implemented — do not write productType to the database for existing elements at all:

php

if ( ! empty( $settings['productType'] ) && ! in_array( 'all', (array) $settings['productType'] ) ) {
    $tax_query['product_type'] = [
        'taxonomy' => 'product_type',
        'field'    => 'slug',
        'terms'    => $settings['productType'],
    ];
}

Workaround (for users affected right now): clear the productType value directly in the database for affected elements.

Confirmed on: Bricks 2.3, 2.3.1, 2.3.2 + WooCommerce. Does not affect Bricks 2.2.

WAIT: Query Edit Php not working
2

Dear @leszek.kotlicki ,

Thanks for the detailed report.

However, we are not able to replicate this issue. A normal query loop with post_type set to ‘product’ didn’t add productType value to the query.

The code you mentioned was in Bricks for more than 4 years (In our repository record)

The control is for Products element. Not a normal query loop.

image
image519×783 30.1 KB

Do you have the BricksUltimate plugin installed + activated?

  • If yes, high possibility additional query parameter was added by the plugin. (I received a few tickets via email channel in the past, had a similar issue, and the users checked with the plugin support) Try create a new query loop while the plugin is deactivated and check the result.
  • If no, kindly let us know how to replicate this issue.

Regards,
Jenn

3

Thank you for the quick and detailed response - and for pointing me in the right direction.

You’re right that the productType control belongs to the Products element, not a standard query loop. That makes sense, and I appreciate the clarification.

To be transparent: I initially attributed this to Bricks because rolling back to 2.2 resolved the issue, while disabling BricksUltimate did not. I now realize that disabling BU doesn’t remove data it may have already written to the database - so the value productType: ['all'] could have been there all along, just not causing problems in 2.2.

That said, I still don’t know for certain who wrote that value to the database or when. I’ll investigate further on my end.

The one thing I’d love to understand better is: why does Bricks 2.3 react to this value when 2.2 did not? The data in the database was the same - something in 2.3 must have changed in how query vars are processed for elements with post_type=product. Any hint on what changed between 2.2 and 2.3 in that area would be genuinely helpful for tracing the root cause.

Thanks again.

4

Hi @leszek.kotlicki ,

It should be this fix. Bricks 2.3.1 Changelog – Bricks

image
image1478×803 67.6 KB

Previously, once the disable query merge is set, these settings no longer work.

image
image451×460 25.2 KB

5

Thank you again - you were right to point me toward BricksUltimate. After digging deeper, here’s what I found.

BricksUltimate is writing productType: ['all'] to element settings (UltimateQuery.php, line 845–846):

php

if( empty( $settings['productType'] ) )
    $settings['productType'] = ['all'];

BU handles this value itself when active - it checks for 'all' before building any tax_query. The problem is that, that value stays in the database and Bricks processes it.

Here’s the interesting part - why this worked in 2.2 but not 2.3.

I compared helpers.php between the two versions. In 2.2, the tax_query was always passed through WC()->query->get_tax_query(), which gracefully handles unknown terms like all. In 2.3, a new skip_request_filters code path was introduced - when active, it bypasses get_tax_query() and passes the raw $tax_query directly. WP_Tax_Query then tries to resolve all as a term slug in product_type taxonomy, fails, and generates AND ( 0 = 1 ).

So the root cause is a combination: BU writes an invalid value, and the new 2.3 code path no longer sanitizes it through get_tax_query() as before.

I’ll report this to the BricksUltimate team.

Thanks for your time and patience.

6

Update - exact trigger identified:

The issue occurs specifically when you use BricksUltimate’s “Ultimate Woo Query Builder” on any element and set the query type to “Products”. At that point BU writes productType: ['all'] into that element’s settings in the database. If you later switch the element back to a standard Bricks query loop - or if you have other elements on the same page using a standard query with post_type=product - those elements will also be affected because the value stays in the database.

In short: using BU’s Woo Query Builder on one element can silently break standard product query loops on the same page, and the problem only surfaces after upgrading to Bricks 2.3.

Fix:

sql

UPDATE wp_postmeta 
SET meta_value = REPLACE(meta_value, 'a:1:{i:0;s:3:"all";}', 'a:0:{}')
WHERE meta_key LIKE '%bricks%' AND meta_value LIKE '%productType%';

Clear cache after running. I’ve reported this to the BricksUltimate team.

4 Likes
7

Thanks you @leszek.kotlicki you saved my friday evening !

1 Like