Hi @wowflak,
I’m sorry, we don’t have support for Toolset fields, so they don’t work out of the box. It might be possible with some custom code to connect the dots there, but would be getting into customizations.
You may have already gathered some of this from your experience with Loopers so far, but let me explain a bit about how Dynamic Content and loopers work together in case it helps in an way.
- When Dynamic Content sees any statement like
{{dc:***}}
, it runs a registered function and tries to return some data.
- If that statement is in the input for the Looper Provider “Dynamic Content”, it will try to coerce the result into an array. If it’s not already an array, it wraps the item in one.
- If that statement is anywhere else (usually text somewhere) the result is coerced into a string.
- You need to make sure however the field is resolved, it ends up as an array. The post meta example above might not work if Toolset doesn’t store their repeater items as an array.
- You can troubleshoot loopers by adding a Raw Content element somewhere inside the provider and using these statements:
{{dc:looper:debug_provider}}
, {{dc:looper:debug_consumer}}
.
- The
key
attribute of {{dc:looper:field}}
supports dot path notation like {{dc:looper:field key="path.to.thing"}}
where each dot reaches into the property of nested object.
So in theory if your top level data is an object, you could consume it and use a {{dc:looper:field}}
to reach down to find the actual array, then point that into another Dynamic Content provider. Unfortunately you may end up with a convoluted tree of elements in that process. We have some improvements planned for Dynamic Content that will let you nest statements which should simplify things a bit more.
I’m sorry I don’t have a more concrete answer. Our current Toolset integration is a very raw way to access fields and wasn’t really meant for anything past getting strings.