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

patch attach

I am marking active again just to make a case about how this issue is in fact different than #1740074: Fix IEF to work when IEF is nested into another IEF

If you still disagree, just close it again.

The other issue is trying to address this issue, and 2 others in one place:

• Nested IEFs do not execute inline_entity_form_save_row_weights so the correct order is never saved
• inline_entity_form_process_entity_form is not executed on nested IEFs so subentities are not saved

Patching the module to fix #1740074: Fix IEF to work when IEF is nested into another IEF will be fairly time consuming whereas this issue is a simpler one, and can be addressed neatly and nicely here first. Then #1740074: Fix IEF to work when IEF is nested into another IEF can adapt to our solution here and move forward addressing those issues.

This issue also relates more closely to Commerce Registration.

I already said I don't want / like the "creating id from parents" approach (since the IEF id shows up in html classes, so it's just ugly.).

I understand how it could be "ugly" but this is how the element "name" values are already calculated in drupal. I got this concept directly from core's theme_form_element()

I suppose you could use something like php's uniqid(), but I would argue that a long string containing the parents of a form element is less "ugly" than a random string of numbers and characters.

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.

There won't really be any need to "use it across the code" -- I know the module currently generates the ID from the $instance param in 2 places, but if you review my initial patch, the second generation (@@ -1093,7 +1093,7, at the end of the initial patch) can actually be replaced by a retreival of the ID from the $form, rather than a new generation.

Attached is a patch that uses a incrementing static variable to generate a fresh ID for each IEF instance. This should fix this issue, but won't address the other problems in #1740074: Fix IEF to work when IEF is nested into another IEF

better?

I'm not sure I understand how there would be a need for that (#10). If $ief_id is already generated cleanly in 1 place (with the patch in #7), why would you need to introduce str_replace('_', '-', $ief_id)?

if it's the dashes vs. underscores you're after -- i could just modify this line in the patch:

+ $ief_domid = 'ief_element_' . $ief_domid;

to be

+ $ief_domid = 'ief-element-' . $ief_domid;

So do you think the suggestion in #12 would work?

I get it now, and agree. I'll send an updated patch today

OK attached is a patch for 7.x-1.x-dev that will do what the above patch did, then make all the "wrapper" elements point to a dash-separated name and let the form name parts use underscores.

I also fixed a comment:

@@ -780,7 +780,7 @@ function _inline_entity_form_get_new_id() {
     $ief_domid = 0;
   }
   $ief_domid++;
-  // Generate unique Map ID.
+  // Generate a unique ID.
   $ief_domid = 'ief_element_' . $ief_domid;
   return $ief_domid;
 }

It said "Map ID" because I copied and modified code from the getlocations module, which uses this to generate unique map id's

forgot to attach

Doesn't this part of the patch take care of that?

@@ -1093,7 +1110,7 @@ function inline_entity_form_field_attach_submit($parent_entity_type, $parent_ent
     if (isset($instance['widget']) && $instance['widget']['type'] == 'inline_entity_form') {
       $field_name = $instance['field_name'];
       $langcode = $form[$field_name]['#language'];
-      $ief_id = $instance['id'];
+      $ief_id = $form[$field_name][$langcode]['#ief_id'];
       // There's no IEF data for this field, skip it.
       if (empty($form_state['inline_entity_form'][$ief_id])) {
         continue;
-- 

no problem splatio.

@bojanz -- can you check out my comment in #20? I think we could mark this as RTBC with splatio's help.