SOLVED: Query Filter options all disabled when the target Query Loop is a The Events Calendar (tribe_events) loop

Bugs
1

Browser: Chrome 110
OS: macOS
URL: https://welcometomosaic.com/events/

Summary

When a Query Filter (Select/Radio/Checkbox) targets a Query Loop whose post type is The Events Calendar’s tribe_events, every option renders disabled (brx-option-disabled) on the front end — even on first load with no active filter. The loop renders events fine, and filtering by URL param returns correct results; only the option UI is disabled, so visitors can’t pick a value.

Two things to rule out up front:

  • The query loop is on the page and renders results (so this is not the known “no query loop on page → count 0” case).

  • The identical filter setup works on a normal CPT — it only breaks when the target is a tribe_events loop.

Looks like a regression: the triggering code is tagged @since 2.3, and this worked before updating Bricks.

Environment

Bricks 2.3.8 · The Events Calendar (free) 6.16.5 and (pro) 7.7.16 · WordPress 7.0 · PHP 8.5 · no other filter plugins · reproduced with our custom code fully disabled.

Steps to reproduce (no access to our site needed)

  1. Clean WP + Bricks + The Events Calendar (free).

  2. Create ~8–10 events across 2–3 Event Categories (tribe_events_cat); include a recurring event.

  3. Enable Query Filters (Bricks → Settings → Query Filters).

  4. Add a Query Loop: post type Events (tribe_events).

  5. Add a Filter – Select, Source Taxonomy → Event Categories, Target = that loop.

  6. Regenerate the filter index.

  7. View on the front end.

Expected: category options are selectable. Actual: every option has the disabled attribute / brx-option-disabled class.

Likely root cause (from source)

In includes/elements/filter-base.php, options are force-disabled when the target query count is 0:

php

// ~line 782
if ( $query_results_count == 0 && $this_active_filter === false ) {
    $option['count'] = 0;
}
// ~line 789
if ( $option['count'] === 0 && ! $option['is_all'] && ! $option['is_placeholder'] ) {
    $option['disabled'] = true;
    $option['class']   .= ' brx-option-disabled';
}

$query_results_count comes from the {query_results_count:<queryId>} tag (~line 118). For a tribe_events loop it resolves to 0 at filter-prep time, even though running the loop’s query directly returns the real total (e.g. found_posts = 132). We believe this is because The Events Calendar rewrites/owns tribe_events queries via pre_get_posts, so the count Bricks reads is 0.

Quick verification: output {query_results_count:<loopId>} on a page with a tribe_events loop — it returns 0 on the front end while the loop renders results. Same tag on a normal CPT returns the correct number.

Already tried (no effect)

tribe_suppress_query_filters via pre_get_posts and bricks/posts/query_vars; adding/removing a date meta_query; regenerating the index; cache purges; bricks/filter_element/populated_options to clear the flag.

Suggested fix

Don’t disable all options based solely on $query_results_count == 0 when the query actually returns posts — or add a filter to override target_query_results_count so plugins like The Events Calendar can supply the correct count.

Thanks!

3

Hi @McNeel ,

Unfortunately, I am not able to replicate this issue following your steps.
I just use the free version. Can you please try to deactivate the Pro version and check if you can replicate the issue?

I remember there is a support ticket mentioning the Pro version does not use WordPress post ID, so there might be a case, and the Events Calendar support provided a snippet for him to solve the issue.

Please first try to deactivate the Pro version to isolate if the root cause is coming from the Pro version.

Regards,
Jenn

4

Thanks for the hint!

Confirmed: deactivating The Events Calendar Pro makes the filters work immediately.

After some digging, it’s specifically Pro’s Custom Tables (CT1) provisional IDs for recurring events: Pro hijacks any query whose post type is only tribe_events and returns occurrence IDs (real post ID + 10,000,000) that aren’t in Bricks’ filter index. The target query count then reads 0 (filter-base.php → query_results_count == 0), so every option’s count is forced to 0 and disabled.

FacetWP documents this same conflict and resolves it by either (a) adding a second post type to bypass the hijack — but that collapses each recurring series to a single parent entry, which isn’t viable for us since the client uses recurring events heavily — or (b) indexing the occurrence IDs.

Ideally Bricks could normalize provisional IDs (TEC’s Occurrence::normalize_id()) in the filter index/count so it works with Pro out of the box. This feels worth prioritizing as Bricks + The Events Calendar Pro is a common combination, and we alone expect to build a number of sites on this exact stack over the next year, so a native fix would have broad benefit.

Happy to test any patch.

Resources:

6

Hi @McNeel ,

Thanks for the info.

Based on our support record, this snippet should work. Can you please try?

Change a1s2d3 to your actual query ID

add_filter( 'bricks/query_filters/get_filter_object_ids', function( $object_ids, $query_id, $query_type, $source ) {
	if ( $query_id !== 'a1s2d3' ) {
		return $object_ids;
	}
	
	$event_ids = [];
	foreach ($object_ids as $event_id) {
        $normalized_event_id = \TEC\Events\Custom_Tables\V1\Models\Occurrence::normalize_id($event_id);

		$event_ids[] =  $normalized_event_id;
	}
	
	return $event_ids; 
}, 10, 4);

Regards,
Jenn

7

This works! Thank you!

Confirming it resolves the disabled filter options with The Events Calendar Pro active, and recurring events still display correctly.

One follow-up so I know how to document this for our sites: should I treat the get_filter_object_ids normalization snippet as the recommended long-term solution, or is there a chance Bricks would handle the provisional-ID normalization natively down the road? I ask because Bricks + TEC Pro is a common stack for us, so knowing whether to keep this snippet per-site or expect a built-in fix would help us plan.

Either way, much appreciated! Happy to keep the snippet in place in the meantime.

9

Hi @McNeel ,

Please treat the bricks/query_filters/get_filter_object_ids normalization snippet as the recommended workaround for The Events Calendar Pro sites that use recurring events. That is the hook created for developers. Events Calendar Pro can use this hook in its plugin code as well.

Regards,
Jenn

1 Like