XF 2.1 Problem with nested field-adder

[Kirby]

We've got the following simplified template code

<xf:radiorow>
    <xf:option  />
    <xf:option data-xf-init="disabler" data-container=".js-hiderContainerType-1" data-hide="yes" />
</xf:radiorow>

<div class="js-hiderContainerType-1">
<xf:formrow>
    <div>
        <div
             data-xf-init="field-adder"
             data-remaining="X"
             data-increment-format="name_{counter}">
                <xf:textboxrow name="textbox_name_{$counter}_label" />
                <xf:radiorow name="radio_name_{$counter}_type"  />
        </div>
    </div>
</xf:formrow>
</div>

This does work fine for the first row, but if a row is added the controls are all disabled.
Now if I select the first option again (which causes all type controls to be hidden) and then re-select the second option, all controls are enabled but if the next row is added by the field-adder, the controls in this new row are disabled once again - this repeats for every row that does get added.

Does anyone have an idea on how to get this working properly (apart from extending the disabler to react on newly added fields)?

 

[Mike]

I actually just ran into that this week. It's from a semi-recent change that sets up the field adder clones at initialization time rather than when the clone is inserted. There are advantages and disadvantages to each approach depending on scenario.

I have made a change to the field adder JS so that the initialization time clone is an option (disabled by default). I didn't happen to see a clear way around it other than that. (Which I know doesn't exactly help you right now.)

 

[Kirby]

I have made a change to the field adder JS so that the initialization time clone is an option (disabled by default).

Will that change appear in a future (next?) XF 2.1 release and if so would you mind sharing the name of the option?
This would allow me to consider this fixed and just adapt my code ot use that option (and patch the core JS for the time being).

 

[Mike]

The change was actually part of 2.2 (as that was where I ran into it), but I've just backported it in to 2.1.8 as it was a change within the 2.1 series.

The default behavior is actually back to clone-on-demand, so it should basically just fix your issue out of the box. If you wanted the other behavior, it'd be data-clone-init="true".