SOLVED: Dynamic data: query_results_count returns 0 for ACF provider loop inside component slot since 2.3.8

Hey,

I’m seeing a regression in Bricks 2.3.8 where {query_results_count:<query_id>} returns 0 for an ACF query loop, even though the loop itself renders the expected items.

Setup:

{
  "hasLoop": true,
  "query": {
    "objectType": "acf_resource_sources"
  }
}

Dynamic tag used elsewhere on the page:

{query_results_count:wrxibu}

Expected result:

3

Actual result in Bricks 2.3.8:

0

The loop still renders all 3 ACF rows correctly, so the ACF data and loop query are working. Only the dynamic count tag is wrong.

This works correctly in Bricks 2.3.6, where the same setup outputs 3.

One possible clue: in 2.3.8, the rendered loop ID appears with a runtime suffix, e.g.

data-brx-loop-start="wrxibu-abc123"

while the dynamic tag still targets the original query ID:

{query_results_count:wrxibu}

Could you check whether {query_results_count} lookup regressed for ACF/provider loops in 2.3.8?

Thanks.

1 Like

Hi @alessandro_benassi ,

Based on your description, you were using query_results_count to target a query located inside a component.

Before 2.3.8, using {query_results_count:wrxibu} will show zero.

In 2.3.8, {query_results_count:wrxibu} should be able to show the correct count.


Linked forum thread: SOLVED: Query Results Count not working in Components - but takes results from inactive template - #9 by bricks.assistant

I did a local test, and it’s working perfectly fine. Can you please provide some screenshots on how you place the dynamic tag? It’s inside a component or outside a component?

Note:
data-brx-loop-start="wrxibu-abc123" is correct if the query is located inside a component. It should be the same in 2.3.6 or 2.3.8

Regards,
Jenn

Hi Jenn,

Funny enough, I’m seeing the opposite of what you described: this worked before, and it regressed after updating.

I jumped from Bricks 2.3.6 to 2.3.8, so the regression may have happened in either 2.3.7 or 2.3.8.

Confirmed setup:

Section component instance
└─ Sources block
   ├─ Text: {query_results_count:wrxibu}
   └─ Query loop: wrxibu
      └─ objectType: acf_resource_sources

In 2.3.6, this outputs the correct count.

In 2.3.8, the loop still renders the 3 ACF rows, but:

{query_results_count:wrxibu}

outputs:

0

As a site-specific workaround, we use a custom echo function:

{echo:xxx_acf_array_count(resource_sources)}

This works because it counts the ACF field directly, bypassing {query_results_count}.

So it seems the component fix may not cover ACF/provider query loops, or this regressed between 2.3.6 and 2.3.8.

This condition in the screenshot will return false. And if I try to output {query_results_count:wrxibu} in a text field outside of the query loop, it will return 0.

Thanks :slight_smile:

Hi @alessandro_benassi ,

I have the same component structure as yours.

Section component instance
└─ Sources block
├─ Text: {query_results_count:wrxibu}
└─ Query loop: wrxibu
└─ objectType: acf_resource_sources

Could it be some custom code or plugin causing this issue? Are you able to replicate this on try.bricksbuilder.io?

Alternatively, you can prepare a staging site and share admin access with us via help@bricksbuilder.io

I will log in and check.

Regards,
Jenn

Hi Jenn,

I’m setting up a test environment and will send the access details via email.

I also tested locally with Bricks 2.3.8 and only ACF Pro active, using standard ACF metadata without ACFE. I separately disabled our relevant custom callbacks. The result remained the same: {query_results_count:wrxibu} returns 0, while the query correctly renders 3 items.

This appears to rule out our custom code, ACFE, and other plugins. It worked in 2.3.6; we skipped 2.3.7, so the regression appeared in either 2.3.7 or 2.3.8.

Thanks,
Alessandro

I forgot to mention in the email, you can find the query in this block:

@alessandro_benassi did you get this sorted out with native bricks? I may be running into the same

Hi @robertobze

I am having an email conversation with Alessandro, confirmed it’s a bug when using {query_results_count} to target an ACF provider loop (Flexible content/Repeater) inside a Component Slot. I just sent him a potential fix zip file to test.

Are you using Component Slot too? You are welcome to send an email to help@bricksbuilder.io and include this forum thread URL as a reference so I can share the zip file with you if you want to try.

Regards,
Jenn

1 Like

then mine my be unrelated or just my setup, Jenn. Thanks.

In my case I built a custom search results page with 5 sections, each for different CPTs, each looping 6 cards.

Then, I added a bricks query loop at the very bottom, and selected > is main query. Then I used the tag above {query_results_count:<query_id>} with the query ID of the query loop at the bottom of the page, but the count doesnt match what is outputted. Maybe its just the logic I am using is wrong.

Hi @robertobze ,

Can you please create a new forum thread with screenshots of your setup? This is a different scenario. I will follow up on yours to check if it’s a bug.

Regards,
Jenn

Hi,

I can confirm the same regression.

Setup (simplified):

  • Component instance with slot content

  • Nested ACF repeater/query loop inside that structure

  • Element condition: {query_results_count:<loop_id>} > 0 to hide the wrapper when the nested loop has no rows

Results:

  • 2.3.7 → works (count is correct, condition behaves as expected)

  • 2.3.8 → broken (query_results_count returns 0, condition hides the block)

  • 2.3.9 → still broken

The nested ACF loop itself is fine; only {query_results_count:…} used in a Condition is wrong, so the whole wrapper never renders.

Same template/condition worked on an older site still on 2.3.3.

Question: Will this be fixed in Bricks 2.4 (or is it already included in the current 2.4 beta)? I’m staying on 2.3.7 for now.

Thanks.

Hi @stabilo ,

The fix will be in the next patch release. It’s not included in 2.4-beta either.

Regards,
Jenn

We’ve addressed this in Bricks 2.3.10, now available as a one-click update in your WordPress Dashboard.

Please read the changelog entry before updating, and let us know if you experience any issues.