Fix IEF to work when IEF is nested into another IEF

Now that's one ugly patch :)

Why are you nesting IEFs? Doesn't that give you horrible UX? I'm tempted to just say "never do that", but I'm prepared to hear your use case.

The IEF ID is the instance id of the reference field (so different for each bundle, yes). Why does that give you a problem?
It should only be a problem if you're using IEF to manage the same entity type&bundle as the parent form (which is a whole new level of crazy :))

From a glance at the current code it seems to me that both inline_entity_form_save_row_weights and inline_entity_form_process_entity_form should work unless there's an IEF ID clash, so waiting for your explanation on that one.

This patch fixes issues that I have then using the IEF with the Commerce Product Bundle module. See #1751140: Integration with Commerce Product Bundle module

I have the same use case

In my case (only tested in firefox), the error given is with allowed memory size exhausted, when I try to edit the nested entity, but the memory limit is about 350Mb... Is normal to consume so much memory?

I got the same error with 1000Mb of memory_limit. I got allways the error in

modules/field/field.form.inc on line 515

Is maybe there some kind of recursion?

I think it could be a good replacement of book module... :)

You present a valid use case, jherencia.
I have a fix in mind, let me roll it.

I have a fix in mind, let me roll it.

Does the fix still lives in your mind ?
Could you point us in the direction you thought about ? I would happily try to implement it as I face the same use case with the same issues.

Cheers.

@garphy and @bojanz

any plans/progress on implementing the nested IEF functionality? We too are facing the issue and are considering to fix. It proves the current code isn't really aware of the nesting-level; only 1 level supported indeed.

Thanks
Koen

related: #1835852: Multiple same-entity add/edit forms on one page results in duplicate DOM Id's

working on a patch..

We need an inline_entity_form_get_id function that returns a fresh id every time it's called (it can have a static variable that is incremented each time).
Then, use it across the code. Should solve all of our problems.

in a patch I attached to the issue referenced in #14 i just used the element's parents to generate an id. It worked to solve an issue I had using IEF with commerce_registration, but i'm not sure how that would work here

@bojanz et al

we're actually trying to patch ourselves now (due to an imminent deadline).
One of the things we want to be certain of, if we e.g. have a
parent, child, and grand child, to not physically write the grand child to the
database, unless we store the parent. Reason is you might end up
with orphan-grand children, if you decide not to store the parent.

With the current code that behaviour is correct, when
storing parent and child (child only is saved when parent is saved).
So just a new function inline_entity_form_get_id I do not believe will do the
entire trick. It would be nice if we could elaborate on how we'ld like to fix,
e.g. using Skype? Would any of the core developers be available?
We'll contribute our fix back to the community.

cheers
Koen

Just a quick update to whom it may concern: we're almost done with an update to the code, to support up to 3 levels of nested IEF forms (so IEF in IEF in IEF). It's hard-coded to max 3 levels; it proved too hard given the time constraints we have, to make it fully recursive.

It's not fully tested yet, and ourselves we don't use it for eCommerce, so we're uncertain how it behaves in that setup. How should we proceed, shall we just upload a patch file here?

Koen

Is there any movement with a patch? Thanks.

@dwalker51 i put up a patch here #1835852: Multiple same-entity add/edit forms on one page results in duplicate DOM Id's but it hasn't been reviewed. I'm currently using that patch on my own production site, but I'm not nesting IEF's I'm just putting multiples out on one page. It might still help you tho.

Thanks but I was trying out nested IEF's my use case was to have: a trip memo -> multiple trips - > each trip multiple photo albums and have the UI on a single page. I am looking at the relation module as well and just doing it individually and then relating them with say a multiple select list. Thanks again!

I also have a use case for supporting nested inline entity forms. @tmsimont I tried the patch that you posted in the other issue, but it didn't work. Would it be possible to get a quick update or status on this feature or plans to include it in a release?

sorry about that cwc -- my patch works in non-nested IEF's on one page, but seems to fail on nested IEF. I'm not sure what the status is on future development of this feature

Got it working in custom case, mayby this could be clue to build general solution.
Would it work by when creating entity form set child attribute and prevent processing in those trigger levels

function inline_entity_form_process_entity_form(&$entity_form, &$form_state) {
  // Only react on submissions triggered by the main submit buttons.
  $triggering_element_name = end($form_state['triggering_element']['#array_parents']);
  if (empty($form_state['triggering_element']['#ief_submit_all']) && !in_array($triggering_element_name, array('ief_add_save', 'ief_edit_save'))) {
    return;
  }
+ // exclude collections being saved from child ief
+ if ($entity_form['#entity']->type=='image_collection') {
+  if(count($form_state['triggering_element']['#array_parents'])>6){
+     return;
+   }
+ }
 #...
}

I also need this. ;) I'm quite new to the code of IEF, and it's too late for me to grok the internals and bojanz's proposal in #15. My use-case is potentially easier to understand than some of the one's described here.

Reviews point to an author (of the review) and point to books (being reviewed).
Books point to authors (of the book)

When creating a review node, I want to IEF the author of the review, and the book that's being reviewed. When I'm creating that book, I want to IEF another author node. My author nodes only have a few fields, so the UI really isn't bad at all (and way better than having to do it all via separate page loads/forms/etc).

Make sense? ;)

Anyway, I'll try to see if this is easy to fix when I look with fresh eyes in the morning...

Thanks,
-Derek

@DWW: Have a look at the referenced issue: #1835852: Multiple same-entity add/edit forms on one page results in duplicate DOM Id's

I have a couple sites with a similar use case to what you've described and it's working well with the patch there. In fact I can't find what specific element from Bojanz's comment or what specific nested use case doesn't work with that patch applied, so this might could end up being marked as a dupe of that.

Thanks! Sadly, that doesn't seem to solve my problems, either. :/ See #1835852-26: Multiple same-entity add/edit forms on one page results in duplicate DOM Id's. But thanks for the pointer, I really appreciate it!

Cheers,
-Derek

I thought he already did (in #15):

We need an inline_entity_form_get_id function that returns a fresh id every time it's called (it can have a static variable that is incremented each time).
Then, use it across the code. Should solve all of our problems.

I haven't jumped into the code to see if that makes sense and how easy/hard it would be, but it seems like a pretty obvious and straight-forward thing... ;)

If this bug becomes urgent enough for my current project, I'll assign this to myself and start working on a patch. Otherwise, I'll just keep following here and am available for testing/reviewing patches.

Thanks,
-Derek

Has anyone made progress on this issue? I've create a node in a nested ief form, it saves the parent entity as many additional times as items that you added. I was able to resolve this using modified code from #24.

I tried both patches for conflicting ief ids on 1.2, but the form ids were only unique for the first two fields (parent and child). Subsequent children had the same elements as child 0 because they shared the id.

I've patched inline entity form to support nesting up to 2 levels deep. I borrowed some ideas from jherencia's initial patch to determine the delta of the root ief widget.

Ids take the form: {parent_field_name}_{instance_id}_{delta}.

The resulting form state inline_entity_form array looks like this:

field_packages_260_0
field_tracks_359_0
field_tracks_359_1
field_tracks_359_2

field_packages is the root widget, and has 3 items. field_tracks 0-2 correspond to each of those items, and can have as many unique items as needed.

In order to support higher levels of nesting, we need to figure out a better way to handle removing settings from form state when a parent item is removed. Currently it uses the delta of the parent being removed to determine the delta portion of the child ief_id (Which works when there is only parent > child type relationships with two fields total).

Adding a depth (0, 1, 2) to the id: {parent_field_name}_{instance_id}_{depth}_{delta} may allow for deeper nesting, but it's problematic to figure out depth when removing elements.

Please test this patch, and come back with your feedback/changes.

Of course there was unnecessary white space. Use this patch instead.

Updating status.

I have started looking into this. We need to rewrite the process function completely.
I am marking all related issues as duplicate (including this one), so that we can all focus on testing one patch.

See you in #2032649: Rework inline form submission.

Minor changes.