Nested dynamic content from ACF - what are the best practices?

We are hitting up against some seeming limitations in the Query and Repeater blocks and want to check the best way to proceed.

One representative example of what we are implementing is a pricing plan grid. This has 3 pricing plans with a toggle for subscription terms and a toggle for currency.

Because we only want the client to have to edit the content of each of the 3 plans once, we created two custom types, a Pricing Plan (containing the price variations and subscription term taxonomy) and a Pricing Plan Detail (containing the various features and benefits).

The idea is to either link the Pricing Plan Detail to the Pricing Plan using a relationship field OR for both the Pricing Plan (variation) and Pricing Plan Detail to both have a related taxonomy that can be used in a sub query.

We have made several attempts to achieve this using various methods and in each case we were blocked by not being able to reference dynamic content (it appears).

The first limitation is, there is no Repeater source in the dynamic selection for taxonomy queries, only WordPress and ACF:

We thought perhaps we could access the repeater via the ACF Field group indirectly but there seems to be no way to get to the fields within each repeater instance that way:

We also thought perhaps there might be a way to reference the fields dynamically using a dynamic inserter or {acffield=fieldname} syntax but that also doesn’t appear to be supported.

As we understand it, nested Queries are not yet supported with frontend rendering, but appear to work without it. We also see that nested repeaters appear to be supported.

We are able to use unrelated nested Queries/Repeaters without issue, we really just need some pointers on the correct way to reference fields and taxonomies in the scope of the parent Query/Repeater from nested blocks.

The open questions we have are:

  1. What is the correct way to reference ACF fields from a Query/Repeater in a nested Query/Repeater?
  2. What is the correct way to do a nested taxonomy query using a term or terms stored in the field of a parent Query/Repeater?
  3. What is the correct way to access the fields of a nested post object stored in a relationship field within a Query?

@Louis, your input will be greatly appreciated. If there is documentation or existing video tutorials that cover this, please just point us in the right direction.

Thank you.

@Araminta, if possible, can you direct us to any existing documentation or examples?

This is the final piece we need to release one of the websites we have been working on, so having some clear guidance on this from Cwicly will be much appreciated.

Thanks.

We are also wondering about potentially using the Query code editor as a workaround in the meantime.

Open questions:

  1. What if any are the limitations of the Query code editor?
  2. What happens if you edit the code heavily and change values in the UI?
  3. What is the recommended way to refer to a parent scoped Query/Repeater and it’s fields if taking this approach?

@StrangeTech Have you ever compared Cwicly’s query builder with Breadance and Bricks’ query builder? Breakdance recently added support for nested queries, and Bricks have had it for quite some time.

Breakdance:

I have received feedback from multiple people that mastering Cwicly’s query builder is difficult due to the huge number of options and infinite possibilities.

Hi @anon32808828,

Nested queries have been possible in Cwicly since day #1 of the query builder…

2 Likes

Yes. I am aware of it. Just stating that the new users get lost in the query builder due to so many options. May be the documentation can host multiple example queries.

Personally, I am a big fan of Cwicly’s flexibility and the possibilities it yields.

Our issue is simply about specific usages that appear to have current limitations, so in all likelihood we are requesting even greater flexibility not less.

While the questions we asked are still valid and will be helpful to get answers for, we have found a solution to our implementation by simplifying everything to use a single Query and have the pricing plan details editable directly within a reusable block.

So yet again, Cwicly prevails!

If I get your problem correctly, you can link the content using the same taxonomy values and then use Query to output “post in a post” this way:

image

Which of these 3 questions does your proposed solution refer to?

If referring to question 2, we have almost solved that using a nested Taxonomy Terms block but have hit against another bug/limitation:

Questions 1 and 3 are still unanswered, they seem to have more complexity and we haven’t found any good information on this yet.

If you are answering about something different, please me know.

It’s question #2.
My solution above shows how to access nested post fields when parent post and nested post have the same taxonomy value associated. No ACF fields used here, just custom taxonomy and its same selected value for both posts.

This way I show fields from “Brand pages” post on “Products” page.

1 Like

Thank you for sharing that - I see now your provided solution covers:

And the gist is to use WordPress > Post Terms to get the parent posts terms in the taxonomy query

Now all we need is nested Queries to be supported for front-end rendering, then this solution can be used within filtered content.

Q1 and Q3 can potentially be resolved through the implementation of custom argument code in the query editor.

Looks like for someone this solution is working, but I can’t get to replicate it.

1 Like

The meta query makes sense to get a new post object - so I can see how this can work with a nested Query now so that answers question 3.

I’m not sure question 1 is fully covered yet though, but this is definite progress!

Ok, here is the solution for the Q3 based on this post.

DALE: The "Doctor And Location Example" With Solutions For Queries, Relations & Other Stuff.

Relational field:

Assigning values in product page:

Query settings:

2 Likes

Yes, I think that covers all of the points now, thank you @Audrius.

Now we just have to wait for until that bug is fixed with front-end rendering of Taxonomy custom field data within a front-end Query.