ECA Form breaks complex IEF widget

The error is caused by \Drupal\eca_form\HookHandler::inlineEntityFormAfterBuild. When I disable that callback by inserting a return $form; into the first line of it, the error disappears.

The problem is that IEF is not creating the correct embedded entity, at the same time there are no error messages or exceptions whatsoever.

Also, selecting an existing entity in such complex IEFs doesn't work either. See also 🐛 Nested IEF (complex form) stopped working for inner form Active .

A matter of fact, IEFs with the simple widget are not affected.

I'll start with an MR to disable the hook handler for complex IEFs so that people can use that patch until we've found a proper solution for this.

Turn out, when we revert the "bugfix" from 🐛 An error occurred while trying to build an inline entity from submitted form values Fixed then the issue disappears as well.

I've now disabled that code block from the other bug fix, but only for complex IEF widgets. This is just a workaround, but that can be applied to avoid that issue for now.

I have now disabled that complex widget hook entirely until we get a solution for this.

Turns out, disabling complex widgets entirely breaks some existing models, that otherwise with the workaround from the MR would be OK.

So, we're now merging and back porting the MR, publish another bug fix release and then hope that we can still find a proper solution for the underlying problem. But at least we would not be breaking anything in the meantime.

@jurgenhaas

Upgrading ECA from version 1.x to 2.x on Drupal 10.3.7 generates a warning related to the use of eca_form alongside inline_entity_form 3.x when initializing content entities using the complex widget with AJAX. The warning message displayed is:

“An error occurred while trying to build an inline entity from submitted form values. This might be a problem if you are using ECA to extend inline entity forms. Please report this to the ECA issue queue to help us improve it.”

Upon investigation, it appears that the condition in the code checks for:

if ($form['#eca_ief_info']['widget_plugin_id'] !== 'inline_entity_form_complex') {

However, in our case, we are using the IEF Table View Mode module https://www.drupal.org/project/ief_table_view_mode → . I would like to suggest modifying this condition to use a regular expression that matches inline_entity_form_complex, which would also account for custom plugins. This change could help ensure broader compatibility.

lexsoft → changed the visibility of the branch 3469697-eca-form-breaks to hidden.

I'm having the same issue as @jurgenhaas described in https://www.drupal.org/project/drupal/issues/3405115 🐛 Argument #1 ($values) must be of type array, null given. Postponed: needs info
Is there a Drupal core patch fix for it?

We are hitting this issue on a bunch of sites -- or rather 🐛 Integrity constraint violation when trying to add multiple blocks in a complex IEF field Active , which I did not think ECA had anything to do with until someone left a comment there about ECA. All of the affected sites have ECA enabled. Here's the gist of what we're doing:

1. Install IEF, ECA Form modules
2. Create a "featured block" entity reference field on a content type, e.g. "Basic Page", referencing content blocks.
3. Set the field to use the complex IEF widget
4. Create a new page, and create a new block using the IEF widget.

If you save now, everything is fine. If you edit the page and add another block, it works fine -- so long as you only ever add one block at a time.

5. If you add a second block without saving the node, it appears correct -- it adds another row to the IEF widget, and you can keep adding more.
6. But if you save, you get the Integrity Constraint Violation, duplicate entry 'xxx' for key 'node__field_uuid_value'.

This is affecting node and taxonomy term references as well as block references -- anywhere the IEF complex widget is used with multiple cardinality, if eca_form module is enabled. Doesn't matter if there's an ECA model using it.

Thanks @freelock for the analysis. I will have to debug this, and it reminds me of 🐛 Entity Form: Build Entity can't process unlimited values Active which also has some strange behaviour for multi value fields.

That issue does sound very similar. One difference is that we were seeing the issue with limited cardinality, too -- although a cardinality of 6... but I'm guessing if ECA is replacing the form_state for some reason that might do it...

I tried to fix this several times with no success. Complexity of Form API plus complexity of IEF makes this impossible for me to find a way to properly resolve this. Also it was a terrible mistake trying to manually rebuild an entity from a simulated form submission in "Form: build entity". Since it looks like no one is able to fix this critical bug, we may want to consider dropping support for IEF (and Paragraphs) entirely from ECA 3.x, and only stick with core's Form API events?

Given that IEFs are always broken with this active, disabling it until it actually works makes total sense to me.

That said, I just spent a little time debugging further, and I think I've at least identified the cause of the issue -- but no solution.

What I'm seeing is that during an Ajax call to refresh the form element, when opening a specific row in IEF, the $context['delta'] is always set to 0 no matter which delta you're actually trying to edit. IEF assumes that the delta is set for the row being edited, but this is not true -- pretty much ever.

It does end up correct like a stopped clock is correct twice per day -- it's correct if the first row edited is the row you're currently editing.

Here's where the delta gets set to zero:

... this is because the delta is not passed in EntityFormDisplay::buildForm to InlineEntityFormBase->form(), so $get_delta is null, and then defaults to 0 in WidgetBase->form().

Meanwhile, by the time we get to the ECA HookHandler->fieldWidgetSingleElementInlineEntityFormComplexFormAlter method, we expect to have the $context['delta'] set correctly, and the entity available in the FormState originally set up under 'eca_ief' -- but it always stores the same entity under the same 0 delta.

So I went to see how IEF determines the delta, and found this:

$delta = $form_state->getTriggeringElement()['#ief_row_delta'];

Plugging that into the ECA hook handler, seems to work! At least for existing rows. If that delta comes back NULL, and we didn't return early, you can't get a new blank form. So I've added a check for if $delta is null, and this at least makes IEF act normally.

Is there a test scenario that actually uses this ECA? I think the MR I'm adding at least fixes IEF, and I would assume would work for alters that act on existing entities -- not sure what scenario might need access to a non-existing entity.

Ok hope I did that right -- I had to merge in changes from the main dev branch and resolve a conflict before it showed mergeable. But this at least fixes the conflict with IEF. Not sure if it breaks any ECA functionality.

Thanks for having another look at this. Tests are not passing yet, thus setting to NW for now.

Not sure if it breaks any ECA functionality.

Given from what we've tried in the past at this place and given that the $context variable once held a delta that worked on our sites (but not anymore?) I guess either way something will change or break at a different place.

Hi,

Ok. So this all made me set up phpunit and figure out how to run these tests, something I've neglected up to now. Got that working, but... I don't understand this test?

It's failing because the "Title" field of the referenced content in the inline entity form is not disabled. But this doesn't make any sense -- most of our uses of inline entity form allow you to edit the title of the referenced entity, and even without the patch applied, the title is editable -- the test is checking for a "#disabled" value that appears to have no effect on the UI. It is set without the patch, but titles are still editable. With the patch, this value is not set -- and the UI is identical here.

So I think the test is invalid -- it doesn't correspond to what it claims to be testing, and what it claims to be testing is not even a relevant test.

I think the test does show that there was no entity attached to the form -- which would be correct, because the form state would not include the IEF triggering event. But we know the old code attaches the wrong entity if you are trying to add an entity using IEF.

We need a better scenario to test.

Ok. Without changing what is actually being tested, I updated the test to set the delta the way IEF actually sets it, so the test now passes (because it is loading the referenced entity into the form, now that the test specifies the delta).

I don't think this is a very good test though...

Regarding the mentioned test: reading from the code it's using a paragraph provided by the Paragraphs → module in an article node and it asserts whether the title field got disabled. You may have missed that the test class is installing the eca_test_inline_entity_form which includes an ECA configuration that disables the title field of the paragraph: https://git.drupalcode.org/project/eca/-/blob/2.1.x/tests/modules/inline...

... this reflects a pretty often used scenario, which is to disable fields in forms.

The test failure proved that the suggested changes in the code break currently existing functionality. The test is using Paragraphs as module, and not Inline Entity Form. The Paragraphs module does not use IEF at all, it has its own implementation of "inline forms". It doesn't make sense to change the test in the suggested way because then it would be "tricked" to have some IEF logic in there.

I recommend to remove the suggested change in the test itself and try to make it green again without changing the test itself.