"Reset the target to its default values when the form is submitted if the dependency is not triggered." checkbox does not work after v4.0.0-alpha6

Its not working

for me after applying patch, its not reseting the value of hidden fields.

@odensc Could you please specify the steps how did you test ? May b I am missing something here ?

I've tried the patch for MR93 on Drupal 11.3.10 with conditional_fields 4.0.0-alpha6. In my testing of this MR, I get an exception 'Error: Call to a member function getDefaultValue() on null' on 'line 848' (the MR says the line that throws that error should be 853 - perhaps another commit to the 4.x branch is impacting?)

My set up is a Node with a Paragraphs field and the paragraph has a Boolean field A and a Text field B. There is a dependency such that field B is visible if field A is checked. The exception is raised when field A is unchecked.

The line that raises the exception is : $default = $entity->getFieldDefinition($field_name)->getDefaultValue($entity);

When debugging, $entity is the Node and $field_name is 'value'. I expect $entity should be the Paragraph and $field_name should be 'field_subtitle' (that's the name of my field B, the target of the dependency).

This is my reading of the code, starting at the line: foreach ($untriggered_dependents as $field) {

• The first few lines allow for the use of either Inline Entity Forms (IEF) or Subforms
• For me, $inline_entity_form_parents is null and $subform_location is 3
• The line that breaks $field_name is: $field_name = end($parents);
• The last 3 entries in $parents are 'field_subtitle', 0 and 'value'. The code picks 'value' which is the attribute name not the field name
• The line that breaks $entity is: if (isset($inline_entity_form_parents)) {
• The previous line set $entity to the Node
• But the 'if' only handles the IEF case - not the subform case - so $entity is not set to the Paragraph

Re-targetting to the 4.x dev branch because that is where we will fix this.

Rerolled the MR the only conflict to resolve was this line
$error_key = implode('][', $error_key_arr ?? []);
to
$error_key = implode('][', $error_key_arr);

One blocker remains: @kenwest's #10 paragraph-subform fatal is still unfixed.

@odensc: in formValidate(), the subform branch derives $field_name from #parents and later calls: $entity->getFieldDefinition($field_name)->getDefaultValue($entity);

For paragraph subforms, #parents can end in value, while $entity is the host node. That makes getFieldDefinition('value') return NULL and fatals.

There is already working subform logic around line 600 that finds the last subform with array_reverse(..., TRUE) and derives the actual field name from array_parents. Please reuse that approach. The current plain array_search() finds the first subform, which matters for nested paragraphs.

Two related guards are needed before dereferencing: confirm the form object provides an entity, and confirm getFieldDefinition() returned a field definition.

A good test to have to make sure we don't end with a regression is a paragraph-subform regression test for #10.

@kenwest: once updated, could you retest your nested-paragraph case, especially the first-vs-last subform handling?

@kenwest Can you have a look at dev branch now that #3501575: TypeError: NestedArray::getValue(): Argument #2 ($parents) must be of type array, null given in ConditionalFieldsFormHelper::formFieldGetValues() is in there as it deals with subforms

My manual testing scenario:

Set up the reported scenario

At admin/structure/types/manage/article/fields, add two plain-text fields: field_a, and field_b with default value Default. Then at admin/structure/types/manage/article/conditionals add a dependency — dependent field_b, dependee field_a, state Visible, condition Value, "widget" values mode, value trigger — and tick "Reset the target to its default values when the form is submitted if the dependency is not triggered."

I was able to reproduce the error @kenwest reported with paragraphs, so will need to fix that before this gets merged as I don't want to create a new bug to fix later. This branch is introducing the problem.

The website encountered an unexpected error. Try again later.
Error: Call to a member function getDefaultValue() on null in Drupal\conditional_fields\ConditionalFieldsFormHelper::formValidate() (line 911 of /var/www/html/src/ConditionalFieldsFormHelper.php).

Hi @joelpittet I was retesting as you requested and just noticed this too

I'll test 4e013b11.

Thanks for jumping on, it’s late for me so heading to bed, but we had paragraphs already in dev/tests so I thought might as well test this issue you brought up with it.

I am an IEF die-hard so I am planning getting tests in for that too. Something for tomorrow but locally paragraphs is not throwing errors, so I feel you might be in for a treat (I hope)

I’ll check back in the morning

Looks like you've nailed it @joelpittet. The Exception is no longer thrown in the case I outlined above in comment #10. If the target field in the paragraph has a default, then it is set to the value of the default when the controlling field is unchecked. If it doesn't have a default, then it is emptied when the controlling field is unchecked. When the controlling field is checked, the value of the target field is untouched.