Can't add more than two items with simple inline entity form widget under some circumstances

Thanks everyone for the time spent on this! I've been banging my head against the same underlying issue I think (I'm one of those using entity browser, eg. see #3226873: Entity reference field with cardinality unlimited - values are deleted when Simple is used → which is closed as dupe for this one).

This seems to be happening because Drupal\inline_entity_form\Plugin\Field\FieldWidget::formMultipleElements() removes the last item to prevent extra entity forms from being created but it also does it in some situations where it shouldn't. E.g. when a user intentionally added this item with the add more button or when saving the form when the element is not yet saved but does have input values.

That's pretty much where I ended up, I think it looks like the items_count getting decremented causes the truncation.

By comparing with the entity browser form array I've managed to get a fairly minimal test case: a button that doesn't trigger submit handlers. If you enable inline_entity_form_test, set it to multiple, and add the following in a form alter, it will cause data loss when pressed:

  $form['actions']['press_me'] = [
    '#type' => 'button',
    '#value' => t('Press me'),
  ];

I've put together a (rough) test patch, it's late now so just posting as is, thanks!

The last submitted patch, 14: 3088901-14-TESTS-ONLY.patch, failed testing. View results →
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

And here's the patch from #13 with the test from #14. Thanks!

I don't know the IEF code very well, so I could easily be missing something (: But I was wondering if we could get by with just ensuring we don't decrement the delta if the form's being rebuilt. Here's a patch just to see what testbot has to say (and I've also improved comments on the test additions). There's no interdiff as it's an entirely different approach.

Thanks!

The last submitted patch, 17: 3088901-17-TESTS-ONLY.patch, failed testing. View results →

#17 is in
tnx

#13 worked for inline_enitty_form 8.x-1.0-rc15

problem was content type with entity reference to a product with variations could only hold 1 variation when saving the content
any other variations was still in the database but the reference was lost from the product level

Automatically closed - issue fixed for 2 weeks with no activity.

Bulk reopen.

We have tested patch #16 on 3.0.0-rc19 and it works. It didn't work for us with patch #17.

Regards

Thanks for the feedback @mnico. Could you elaborate a little on how it's failing? Is it simply failing to make any difference at all to the behavior? Anything in the console? I tried locally using the test module against latest (c753ec180166fd9a12af9d9d047730d2ee2650b6) and the patch in #17 still seems to fix the issue where an ajax callback that doesn't trigger submit handlers can lead to data loss. Maybe there's another issue at play here?

I tried to rerun the tests on #17 but the patch didn't apply, here's a reroll.

Thanks!

Hello, to reproduce the issue a third level of references must be configured, an example is:

1. Create 3 types of content: "First", "Second" and "Third" respectively.
2. Create the Reference field in the content type "First" and point to the content type "Second" (unlimited). And configure the "Simple" Widget.
3. Create the Reference field in the content type "Second" and point to the content type "Third" (unlimited). And configure the "Simple" Widget.

I attach an example of the resulting form when creating content of type "First":

With this configured, the bug will occur at the third level. If I apply patch #16 it fixes it, but not with #17.

Regards

Thanks for the detailed description @mnico. Moving to NW to catch #26 in a test.