Move the inline forms (add, edit, remove, reference existing) to modals

Good idea, I'm interested on this.

That would make this module a near 100% duplicate of references_dialog.

My main complaint with the plan for v2 is that it doesn't make sense for the module's name to be Inline Entity Form if the subform is not inline :) Making it a configurable option would be the best approach, IMHO.

I'm too intersted for this solution. For now there is posibility lost data if user chose edit referenced node and save parent node without saving referenced node.

Is there any ETA on modals? I'm happy to pitch in however I can.

In the meantime, is there any kind of workaround? I'm assuming it's more than just adding a "colorbox-load" or "ctools-use-modal" class to the buttons.

This would be a huge UI improvement for my use cases, so you have my undivided attention if you need it.

Please and thank you!

My customer desperately wants a particular node type to edit in a modal window, so I've been looking all over Drupal. This is a very common request and has been nearly accomplished. The problem seems to be that if anything inside the modal box is also Ajax'ed, then either that thing or the modal box provider get confused and break. If you can fix this issue you will be doing the Drupal world a major favor.

@NancyDru
I think entity connect is what you can try and it is working fine with dev version. You can edit the referenced entity(ER field) using edit button which will be shown based on the configuration setting of that field.

feature req:
As for the inline entity form it would be great if it show two radio button
1. existing : which will show autocomplete or select list( view as source for large list)
2. new : show the form of reference type just as it is showing.

This could be like conditional widget just like conditional fields.

BTW someone just uploaded IEF_Dialog: https://www.drupal.org/project/ief_dialog

Hello,

Not sure if it's better to open a new issue or update this one.

As modal is now in Drupal 8 core, maybe it would be a good thing to add this support in IEF for D8 ?

That would make this module a near 100% duplicate of references_dialog.

(#2)
Well, maybe sort of, but until now, there are no plans for a D8 version of References Dialog, see this issue.

Exploration of this problem (...) showed that modals aren't flexible enough for IEF because you can always have only one.

(#10)
Are you generally speaking? With References Dialog 7.x you can use nested modals very well.

@DamienMcKenna and @bojanz, your comments refer to IEF 7.x. What do you think about modal dialogs in 8.x?

See also #1881616-10: Move the inline forms (add, edit, remove, reference existing) to modals:

Exploration of this problem (done by slashrsm and me) showed that modals aren't flexible enough for IEF because you can always have only one.
This means no nested IEFs, no possibility for an entity form to open a modal for their own purpose.

In #3051990-4: Refactor IEF based on Commerce InlineForm API improvements as a 4.x major version @bojanz clarified about modals and nested subforms:

A percentage of IEF users likes to nest them, up to several levels (e.g. products -> variations -> billing schedules). At the time we were concerned about leaving those users behind, especially since the goal of 8.x-1.x was to provide feature parity to D7. This worry was in part because the 8.x-1.x codebase is a monster, the Complex widget holds most of the real code, and it's not reusable. I'd love to see 8.x-2.x have more reusable elements which would allow people to build all kinds of alternative widgets (such as reference-first, etc) for different use cases.

I don't know if there's a problem with other module's modals as well. If we're editing a variation in a modal, can we use media library for variation images? Can the media library be opened?

Still, I think it's worth exploring, for the gain in UX and code quality. People who nest IEFs can combine different widgets (so, you use the Table widget to manage variations on a product, but then use the Embedded widget to manage another entity on the variation)..

Thanks for clarifying! I'll definitely keep this in mind when working on the other things. Some thoughts...:

UX-wise i like the idea of a modal, too. OTOH i'm a quite hesitant of cutting off support for nested use cases.
Maybe we can (like entity_embed) let people choose between modal and iframe (which should not be a problem to nest) and only have minimal variation in code paths between these alternatives. (We even might replace the iframe with a server-side subrequest.)

I do grok that the modal being populated in a separate request does not play well with the current inner working of FormState. I remember digging in entity_embed and AFAIR that too leverages Tempstore. But i too remember quite some PITA when a contrib module wants to hook into that form/subform communication (for things that are simple in embedded forms, so let's be prepared for some headaches with this.

In any case, what we (IEF) and entity_embed (and maybe others) essentially do is a variant of FormState that plays well with subforms in separate requests, so my strong gut feeling is it's worth giving this some conceptual thought and work together on abstracting this ("FormState NG plus SubformNG").

Maybe we can (like entity_embed) let people choose between modal and iframe (which should not be a problem to nest) and only have minimal variation in code paths between these alternatives. (We even might replace the iframe with a server-side subrequest.)

Isn't the Entity Embed Modal plugin still just a modal with a iFrame within?

> OTOH i'm a quite hesitant of cutting off support for nested use cases.

We use nested IEFs on my current project. I've used them elsewhere before too.

We also use nested IEFs quite a lot. I wonder how hard #2741877: Nested modals don't work: opening a modal from a modal closes the original is.

#20 We've solved that problem in Layout Builder Modal module.

On the image above we can see that there are three types of dialogs rendered. The off canvas in the background, the Layout Builder Modal modal dialog and then the CKEditor image dialog.

Our solution (which I believe was first found in that linked issue from you) is that we use dialog as dialog type instead and then use the modal option for that dialog type. https://api.jqueryui.com/dialog/#option-modal

    $links['layout_builder_block_update']['localized_options']['attributes']['data-dialog-type'] = 'dialog';
    $links['layout_builder_block_update']['localized_options']['attributes']['data-dialog-options'] = Json::encode([
      'width' => $config->get('modal_width'),
      'height' => $config->get('modal_height'),
      'target' => 'layout-builder-modal',
      'autoResize' => $config->get('modal_autoresize'),
      'modal' => TRUE,
    ]);

There are some outstanding issues like:

#3065095: CKEditor native dialogs not clickable inside of jQuery UI dialogs - There is a failing patch and work-arounds available
#3075236: jQuery UI dialog modals repositions incorrectly on window resize when there is a off canvas rendered - Might not be applicable for IEF's use case though