Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Currently there is no way in entity form to support a widget that can be used to edit several entities directly like the following example:
- inline_entity_form_single only works for cardinality 1, and does not respect cardinality.
- inline_entity_form mandates that you have an UX where you can only edit one entity at a time.
After talking with Bojan, he suggested I could fix inline_entity_form_single to support cardinality or name a new widget that would use most of its logic but support multivalue direct edit.
Comment | File | Size | Author |
---|---|---|---|
#40 | inline_entity_form-1960686-node-edit.png | 426.08 KB | bdone |
#40 | inline_entity_form-1960686-ief-multi-edit.png | 357.49 KB | bdone |
#40 | interdiff-1960686-30-40.txt | 8.78 KB | bdone |
#40 | inline_entity_form-1960686-40.patch | 8.97 KB | bdone |
Comments
Comment #1
hernani CreditAttribution: hernani commentedInitial patch attached. It adds a new widget and reuses most of the logic of already available widgets. Support for correct order of values and does not insert blank values.
Comment #2
hernani CreditAttribution: hernani commentedFor reviewing
Comment #3
vasikeit seems the path couldn't be applied as it is, there's an issue about the paths used for the changed files (/docroot/sites/all/modules/contrib/inline_entity_form/ shouldn't be present in these paths).
and it seems it has errors for Commerce products - tried with Commerce Kickstart:
Notice: Undefined index: sku in CommerceProductInlineEntityFormController->entityForm() (line 192 of /kickstart_path/profiles/commerce_kickstart/modules/contrib/inline_entity_form/includes/commerce_product.inline_entity_form.inc).
Comment #4
bojanz CreditAttribution: bojanz commentedWe should modify the "single" widget to behave like this when cardinality is > 1, and rename the widget to "simple" then (so we have "Simple" and "Complex", complex being the regular multiple values one with the table and "add existing").
Comment #5
hernani CreditAttribution: hernani commentedBojan,
The idea will then be to have a patch that fixes the behavior of single to support multiple cardinality and renames the widget as well?
Comment #6
bojanz CreditAttribution: bojanz commentedYes.
Comment #7
Kristen PolI tried applying the patch to latest IEF and it was rejected:
Comment #8
almc CreditAttribution: almc commentedWould the development of this feature be continuing? It seems to be what could be an important organic feature of the core - to have multiple entities entry widget similar to fields (with Add and Remove buttons and cardinality from 1 to unlimited). Sometimes it would be much more efficient than using the field collection module.
Comment #9
arpitr CreditAttribution: arpitr commentedI tried using the patch using patch command and also by using manual way. The function mentioned in the patch as @@ -855,6 +887,37 @@ function inline_entity_form_process_entity_form(&$entity_form, &$form_state) {} does not exist in inline_entity_form module.
Comment #10
DamienMcKennaI've been rerolling this, but the API has changed sufficiently and I haven't worked out the correct replacement for the following:
The attached file includes everything else.
One small thing - I renamed the widget from "inline_entity_form_multiple_direct_edit" to "inline_entity_form_multiple_edit".
Comment #11
DamienMcKennaLets move the feature request to have a table-based edit form into a new issue: #2238003: New widget: multiple items, table-based editor
Comment #12
DamienMcKennaThis might be it, but I suspect inline_entity_form_entity_form_submit() needs work.
Comment #13
DamienMcKennaThe patch needs some work - while the fields show up correctly, they're not handling the validation correctly.
Comment #14
DamienMcKennaThe patch also fails to provide a way to remove items from the list or provide a way to add new ones. It really needs some work :-\
Comment #15
DamienMcKennaI'm going to try redoing this to just auto-open the edit form for the existing multi-item widget, see if that works.
Comment #16
DamienMcKennaThis is a WIP patch that will, eventually, provide a checkbox on the field settings page that lets entities always load the 'edit' form, and it replaces the 'cancel' button with the 'remove' button. There are still problems with it, e.g. sorting doesn't work, and saving the form creates all sorts of crazy errors, and there isn't a checkbox to enable the always-edit option (it's basically hardcoded), but I wanted to save what I have so far.
Comment #17
DamienMcKennaFurther WIP, there's now a field setting to control whether the multi-edit functionality is loaded, completely removing the need for a separate widget. I still need to fix a problem where you get a face/screen full of error messages, but the data is at least being saved correctly.
Comment #18
DamienMcKennaOops, forgot to include a change to "includes/entity.inline_entity_form.inc".
Comment #19
DamienMcKennaAfter some further testing, the errors I was seeing were because of #2237097: Support for inline_entity_form, this patch seems to work nicely.
Comment #20
capnut CreditAttribution: capnut commentedThe patch does work and it's great usability improvement for specific cases!
Additional suggestions:
* add a button with functionality to save all edited items at once
* add an ability to choose a specific display style to control how the actual nested form looks like -- although it is probably a scope for a new widget altogether
Comment #21
DamienMcKenna@capnut: IIRC, hitting save on the parent entity will cause the sub entities to also save.
Comment #22
capnut CreditAttribution: capnut commentedIndeed, "save" on parent entity saves the new values or changes of entities in inline entity form with multi-edit enabled as well :)
Comment #23
DamienMcKennaA small tweak, this ass the 'form-actions' class to the actions button group.
Comment #24
vasikeI can confirm the latest patch worked.
There is a new patch that adds to previous patch:
1. Sorting/Ordering, also fix the ordering for default open Edit forms.
2. Remove the Fields Headers for Multi-edit (fields cells with colspan).
3. Remove the Save/Update button for Multi-edit, i don't think we need this for All Open edit forms.
4. Use "Product title (SKU)" for Fieldset title of every product on Multi-edit.
I hope we're closer now.
Comment #25
daulet2030 CreditAttribution: daulet2030 commentedI tried the patches against Inline Entity Form 7.x-1.5+6-dev it has some conflicts and doesnt work properly. What version are these patches for? Am I missing something?
Comment #26
DamienMcKennaLooks like we need a reroll.
Comment #27
CatherineOmega CreditAttribution: CatherineOmega commenteddaulet2030: the patch in #24 applies cleanly to 7.x-1.5+6-dev for me. Did you attempt to apply any others?
Comment #28
daulet2030 CreditAttribution: daulet2030 commentedWell, silly me, I started applying from patch #10 through #24, when I just need to apply #24!
It works, it opens edit forms for all entities referenced if you tick "multi-edit".
However, it's still not in table form(as shown in picture). As I understand from code, it only supports table form for commerce module. A generic entity will need to define its own inline entity form controller with overriden EntityInlineEntityFormController::tableFields() to display its fields in a table row?
Comment #29
DamienMcKenna@daulet2030: We're focusing this issue on making the multi-edit functionality work in the first place, #2238003: New widget: multiple items, table-based editor is focused on making it work as a table.
Comment #30
daulet2030 CreditAttribution: daulet2030 commentedYeah, sorry about that, you already stated that in #11. I got confused by the picture.
Comment #31
DamienMcKennaRerolled.
Comment #32
DamienMcKennaClosed a duplicate: #2225675: Inline entity form - OPEN - already loaded form - Missing markup
Comment #33
DamienMcKennaI believe the latest patch has a problem with file fields, when attaching a file it gives the following error:
Notice: Array to string conversion in form_process_checkbox() (line 3217 of includes/form.inc).
Comment #34
iampumaTested the latest patch from #31 against 7.x-1.5 and it works great. I did not have any file field issues though.
Comment #35
nmalinoski CreditAttribution: nmalinoski commentedOne thing this would help with is display of custom entities that do not use the title attribute (Such as those that can be created with ECK); if you don't specify a title, all you get is a nid, which isn't helpful at all.
Comment #36
szeidler CreditAttribution: szeidler at Ramsalt Lab commentedNot sure, if that issue is still meant to be active. I had the same use-case and needed rerolled the patch. It should work against the current dev, which also applies to 7.x-1.8.
edit: sorry. there seems to be a major issue with the attached patch. I will investigate what it's all about
Comment #38
szeidler CreditAttribution: szeidler at Ramsalt Lab commentedComment #39
ptsimard CreditAttribution: ptsimard commented@szeidler, have you found what was the issue with your patch?
While content modeling today I ran into this exact use case and issue that #35 is talking about (ECK without title).
Comment #40
bdone CreditAttribution: bdone as a volunteer and at Red Hat commentedre-roll of #30 against 7.x-1.x (492f460d), with screenshots.