Browser: Chrome 110
OS: macOS / Windows / Linux / etc.
URL: Link to a page that illustrates this issue
Video: Short screen recording that illustrates this issue (free tool: jam.dev)
Hi,
I’m having an issue that I’m not sure is a bug or just a configuration problem. It deals with nested ACF query loops involving Flexible Content, a Repeater, and a Post Object field. I worked the best I could with Claude to try and address this, but it narrowed down to a potential bug and told me to report it.
In the pictures, “The Fur Trader’s Lady” is the first Layout, “The Story She Left Behind” is the second layout. “The Story She Left Behind” is the correct object that was added on the back-end, but you will see the ones following it are objects from the first Layout and not what was actually added on the back-end. Everything after “The Story She Left Behind” is supposed to be entirely different objects.
-–
SUMMARY
When using multiple instances of the same Flexible Content layout, each containing a Repeater with a Post Object query loop inside, the first repeater item of each layout instance resolves correctly, but all subsequent repeater items in the 2nd and later layout instances display the Post Object data from the previous layout instead of their own.
-–
ACF FIELD STRUCTURE
- Flexible Content field
-
Layout: layout_book_tag
-
Repeater: book_tag_select
- Post Object: book_tag_book
-
-–
BRICKS SETUP
- Container with Query Loop → Flexible Content (layout_book_tag)
-
Container with Query Loop → Repeater (shown in Bricks as “Books (Layout) (Book Tag)”)
- Container with Query Loop → Posts, Include: {acf_layout_book_tag_book_tag_select} (the Post Object option Bricks provides in the Include dropdown)
No custom code. Everything configured using Bricks’ native dropdowns and dynamic tag picker only.
-–
EXPECTED BEHAVIOR
Layout 1 → Repeater item 1 (dog)
, item 2 (cat)
, item 3 (rabbit) ![]()
Layout 2 → Repeater item 1 (rooster)
, item 2 (hen)
, item 3 (chick) ![]()
-–
ACTUAL BEHAVIOR
Layout 1 → Repeater item 1 (dog)
, item 2 (cat)
, item 3 (rabbit) ![]()
Layout 2 → Repeater item 1 (rooster)
, item 2 (cat)
, item 3 (rabbit) ![]()
Items 2 and 3 of Layout 2 are displaying the Post Object data from items 2 and 3 of Layout 1.
-–
KEY OBSERVATIONS
1. Layout 1 works perfectly in all rows.
2. The first repeater row of Layout 2 is always correct.
3. From the second repeater row of Layout 2 onwards, the Post Object data matches Layout 1’s rows at the same index positions.
4. This is entirely reproducible and consistent — it is not random.
5. The dynamic tag {acf_layout_book_tag_book_tag_select} is the only option Bricks presents in the Include picker for the Post Object field. No alternative path is available through the UI.
Per Claude: This suggests Bricks is failing to re-evaluate the {acf_layout_book_tag_book_tag_select} tag per repeater row after the first Posts loop fires within a layout instance, and instead reuses the resolved values from the equivalent row positions of the previous layout.
I know this is long-winded, but does anyone have insight? Thanks!!

