Hello,
I’m building a recipe template with Bricks 2.3.1 and ACF Pro. The data is a nested ACF repeater: steps → components → ingredient rows, where each row has a field show_at_step that indicates which step the ingredient should appear under.
Structure in Bricks (see screenshots)
-
Outer markup: ordered list for steps.
-
Loop 1 (element ID
iotija): ACF repeater for recipe steps. -
Loop 2: ACF repeater for components within the current step.
-
Loop 3 (“Ingredient Loop”, e.g.
hrxklt): ACF repeater ingredient rows inside components.
Goal
In the Ingredient Loop, output only rows where show_at_step equals the current step index (from loop iotija, 1-based).
What I tried in the builder
Under Query → Results filter, I set:
-
Value 1:
{acf_ingredient_rows_show_at_step} -
Compare:
== -
Value 2:
{query_loop_index:iotija @start-at:1}
I expected the filter to consistently use the outer step loop’s index even when the query runs three levels deep.
What I’m seeing
In practice, {query_loop_index:…} in that context does not seem to resolve to loop iotija; it behaves more like the inner loop’s index (or comes back empty/wrong), so the results filter doesn’t behave as expected.
Workaround
I’m using bricks/query/loop_object (on the step loop) plus bricks/query/result (on the Ingredient Loop) to filter rows in PHP, which works.
Questions
-
Is
{query_loop_index:<other-loop-element-id>}in a deeply nested query’s results filter meant to always use the index of that named parent loop? -
Is there a recommended builder-only approach (results filter, different dynamic data syntax, or loop ordering) for three-level nested ACF repeaters?
-
If this is an edge case, would clearer parent-loop context in filters be reasonable as a feature request?
Screenshots: (1) Ingredient Loop query + results filter, (2) structure tree (Steps → Component Loop → Ingredient Loop).
Thanks for any insight or similar experiences.
(1)
(2)
