Parent form entity builders run on IEF resulting in fatal errors

Note that this does not happen on 1.x. Downgrading from 2.0.0-rc4 to 1.0.0-rc15 allowed me to same the IEF successfully.

Experiencing the exact same issue.

I can attest that this is also throwing the following error as well: InvalidArgumentException: Field "" is unknown. in Drupal\Core\Entity\ContentEntityBase->getTranslatedField() (line 587 of /app/web/core/lib/Drupal/Core/Entity/ContentEntityBase.php).

Basically, it's trying to fetch the fields of the parent entity as well. I believe the last change here might be culprit.

The form has become unusable as we can't save or cancel out of the referenced forms while editing. Have changed the priority to "Major".

I'm having the same error while editing an existing paragraph element, using 2.0.0-rc4.

Downgrading to 2.0.0-rc3 resolve the issue.

I'm having a similar issue and can confirm using 2.0.0-rc3 resolves the issue.
It seems this error is related to 🐛 IEF does not invoke hook_entity_prepare_form Fixed .

For now, I created a patch that reverts that issue, which seems to resolve my issue.

Can confirm that this is still an issue in 2.0.0-rc7 and the provided patch (#7) resolves the problem

Came across this exact issue today when using the Storage module (loading storage entities on a node using IEF).

TypeError: token_node_menu_link_submit(): Argument #2 ($node) must be of type Drupal\node\NodeInterface, Drupal\storage\Entity\Storage given in token_node_menu_link_submit() (line 692 of modules/contrib/token/token.module).

And

TypeError: Drupal\inline_entity_form\TranslationHelper::updateEntityLangcode(): Argument #1 ($entity) must be of type Drupal\Core\Entity\EntityInterface, null given, called in /var/www/html/web/modules/contrib/inline_entity_form/src/Plugin/Field/FieldWidget/InlineEntityFormSimple.php on line 191 in Drupal\inline_entity_form\TranslationHelper::updateEntityLangcode() (line 76 of modules/contrib/inline_entity_form/src/TranslationHelper.php).

Depending on the site.

Downgrading IEF from 2.0.0-rc7 to 8.x-1.0-rc15 also fixed the problem for me.

I'm seeing the same as #4, using an IEF widget referencing a node type that has a content moderation workflow, referenced from a node type that has a different content moderation workflow. The IEF widget cannot be updated or cancelled.

Patching the issue with #7 does work.
However, this means the prepare form hook isn't invoked anymore. Maybe a better solution would be to patch the menu_ui core module to implement EntityInterface in its function arguments and then check with an if statement wether the entity implements NodeInterface.

This was indeed caused by 🐛 IEF does not invoke hook_entity_prepare_form Fixed . The problem is that the *_prepare_form hooks send both an $entity object directly, and $form_state. Any hooks that make use of $form_state->getFormObject() (and $form_state->getFormObject()->getFormEntity()) will get the form object and associated entity for the main/parent entity being edited, not the inline entity that needs to be prepared. This is why it's causing multiple issues across the board.

For instance, in the case of content_moderation incompatibility, Drupal\content_moderation\EntityTypeInfo->entityPrepareForm() interacts with the form object but in doing so uses the inline $entity passed to create a new revision and then call $form_object->setEntity(), overwriting the main entity associated with the form object with a new revision of the inline entity sent to the hook.

I spent some time trying to figure out a reasonable way to work around this, but I am not sure that one exists. It would be possible to temporarily override the entity on the form object with ->setEntity() before calling hooks for an inline entity, then set it back to the original afterward. But this still doesn't address that the form object itself will still be for the main form/entity. Logic that uses the form object, such as in content_moderation, will still be incorrect.

I think there's a strong case for going ahead with reverting 🐛 IEF does not invoke hook_entity_prepare_form Fixed for now. It simply is not working as intended. A path forward for invoking that hook properly must include instantiation/use of a form object specific to the inline entity and inline entity form.

Attached patch does what is suggested in #15 and reverts the code from issue 3015323.

Obviously this is not a permanent solution, but it allows our editors to do their work. I'm not knowledgable on the inner working of entity handling to know what other effects this could have.

I'm currently using the Inline Entity Form (IEF) module to manage the Bricks module → . With IEF version 1.0-rc15, everything worked seamlessly on Drupal 9. However, upon upgrading to Drupal 10, I encountered a critical issue preventing the editing of any brick. The error message is as follows:

LogicException: Entity type brick does not support revisions. in Drupal\Core\Entity\ContentEntityBase->setNewRevision() (line 293 of /app/web/core/lib/Drupal/Core/Entity/ContentEntityBase.php).

Upon investigation, I traced the error back to the EntityInlineForm::invokeAllWith method. Applying the patch from #16 resolved the issue. I hope for a permanent resolution to this matter in the near future. Thank you."

This might be fixed in the 3.x branch? I just updated a test site this morning from 2.0.0-rc4 => 3.0.0-rc19 and the issue is no longer present.

Can anyone else confirm if upgrading to the 3.x branch also fixes the issue for them?

I confirm that upgrading to 3.x fixed the situation.

Marking as RTBC

IEF 2.x got some commits that should not have gotten in, this is one of them. Please update to IEF 3.x.
Updated that issue with guidance for this regression not to happen again.
Closing this as the revert is in 3.x.