Browser: not browser-relative
OS: not-OS relative
URL: Link to a page that illustrates this issue
Main problem: Query Filters indexer scans ALL post types for filterSource: "taxonomy" — causes stuck/timing-out indexing jobs on large WooCommerce catalogs (8000 products+ with variants)
Detail description:
Hi guys,
I faced an issue with indexing on big e-shop and maybe found a solution. See details below:
For filter elements using filterSource: "taxonomy" (e.g. custom product attribute taxonomies like product-colour, product-brand), the index-job query in Query_Filters_Indexer::get_index_args() builds the WP_Query with post_type set to all registered post types:
// includes/query-filters-indexer.php
$post_types = array_diff(
get_post_types(),
[ 'revision', 'custom_css', 'customize_changeset', 'oembed_cache', 'user_request' ],
);
This means indexing a single product-attribute taxonomy filter scans product, product_variation, attachment, shop_order/shop_coupon (non-HPOS), pages, posts, etc. — not just the post types the taxonomy is actually registered against.
By contrast, the built-in WooCommerce wcField filter source does scope its query to post_type => 'product' only (includes/integrations/query-filters/woocommerce.php wc_job_index_args()), so this looks like an inconsistency rather than intentional behavior.
Impact
On a WooCommerce store with ~8000 products (variable products with multiple variations, several custom attribute taxonomies), indexing jobs for taxonomy-sourced filters would start, make partial progress, and then consistently stall around the same offset on every retry (via WP-Cron, the background AJAX trigger, and even a direct do_action('bricks_indexer') call bypassing HTTP entirely) — pointing to the query itself being the bottleneck, not a transport/loopback issue. With product_variation alone easily reaching 20–40k rows on this catalog, the resulting JOIN against wp_posts/wp_term_relationships across every post type is heavy enough to hit PHP’s time/memory limits on ordinary shared hosting, well before resource_limit_reached() gets a chance to checkpoint progress.
Suggested fix
Scope the query to only the post types the taxonomy is actually registered for, using core’s own registration data:
$tax_obj = get_taxonomy( $filter_taxonomy );
if ( $tax_obj && ! empty( $tax_obj->object_type ) ) {
$args['post_type'] = $tax_obj->object_type;
}
This is safe and fully general (works for any taxonomy, not just WooCommerce ones) since object_type is exactly the set of post types the taxonomy was registered against — no risk of missing matches for taxonomies that legitimately span multiple post types.
Workaround (in case others hit this)
Until fixed, this can be worked around with a mu-plugin using the existing bricks/query_filters/index_args filter:
add_filter( 'bricks/query_filters/index_args', function( $args, $filter_source, $filter_settings, $query_type ) {
if ( $filter_source === 'taxonomy' && $query_type === 'wp_query' ) {
$taxonomy = $filter_settings['filterTaxonomy'] ?? '';
$tax_obj = get_taxonomy( $taxonomy );
if ( $tax_obj && ! empty( $tax_obj->object_type ) ) {
$args['post_type'] = $tax_obj->object_type;
}
}
return $args;
}, 10, 4 );
Deploying this fixed the stuck-indexing-job issue on our site immediately — jobs that previously never completed now finish normally.