Prioritize 'add existing' in nested entity creation UX to prevent duplication.

I would be happy to see this done as a new widget, inside this module or in a contrib that depends on IEF.

You probably wouldn't be able to take the entered autocomplete value and use it on the add new form though.
However, it's enough to offer a row of autocompletes with an "Add entity" button instead.

This is very good idea indeed. Closed similar issue as duplicate to this.

I asked for exactly the same improvement. As I use it for Terms the interface could be different tough- as the term gets generated anyway when typing a value that's not present it should somehow (after submitting) pop up ;) a form to fill in the remaining fields for the just created (term) entity?

My idea about improved UI is described in #2679355: Add new only after add existing, which I closed as duplicate for this. I wanted to have one button, but this is something UX should discuss.

Big +1

Huge +1 :)

Couldn't we alter the autocomplete results to have something like "+ Create My input" at the end of the results that would trigger the form if selected?

+1 here. Very bad UX and the only reason I don't use this module.

The "Simple widget" cannot search in existing entities. It just presents an empty form to add new entries.
The "Complex widget" is what it says. It is really complex. User has no idea if something preexists or not so has to try both buttons. And the leftmost, which is the most important one, is add new. So the right sequence would be click right button, search, if not go back, click left button, add new entry. I would love if these 2 workflows were combined. And I think in that case we wouldn't need 2 different widgets.

Any updates on this. Would be a great feature. If there is code sitting somewhere I would be willing to help push forward. Thx.

I'm be super happy to help anyone who wants to take the effort and help improving the UX. Just ping me when you have ideas and time :)

I needed something like this: Presenting the form to reference existing entities by default (for empty fields) but keeping the ability to add new entities.

Instead of creating a new widget, I took the simpler path (because IEF widgets are complex) to add an option to the IEFComplexWidget: The ability to chose a default mode for empty fields.

This works beautiful and IMO fits into the feature set provided by the ComplexWidget.

If both new and existing entities are allowed an option is shown to chose which form to present on empty fields: The buttons (default), the form to add new entities or the form to add existing entities.

Patch is attached.

Added config schema and made the reference form not throw errors when submitted empty.

Looks great at a glance, keep going please :)

Happy to review when you are done. This is so much needed!

Re-wrote the title to be more specific

I don't really understand the test fails yet (can't reproduce by taking the same steps in my environment). I'll try to find the time to debug, if someone else wants to chime in you're more than welcome.

Patch #12/#14 is definitely a step forward, but only works for IEF fields with a single item. On a multi-item field after entering a first item, the behavior is just like before.

Has there been further development? This patch is very interesting, but can only be used for one single field. If there are several IFF or an IFF with multiple values, the field only shows the changes for the first field or value.

Another problem: when I apply this patch, even when the reference field is not mandatory, an error appears that the autocomplete field is mandatory.

Re: the multi-item field issue - the prioritized widget was set to switch in when there were no inline entities in the form - if you remove this condition, the prioritized widget will show even if inline entities have been referenced/created (i.e. if items are present).

Re: the test fails - I assume this is due to the wording of the submit buttons being changed, but not updated in the tests. I've added some code to the web test to set the empty mode for the widget, and to use that in the testEmptyFieldIEF() method to add steps to test the empty_mode options.

Would it be better to test on the name attribute rather than the value of the submit buttons? e.g. :

• name^=["ief-add-submit-"]
• name^=["ief-add-cancel-"]
• name^=["ief-reference-submit-"]
• name^=["ief-reference-cancel-"]
• name^=["ief-switch-mode-"]

Also we could DRY the tests by adding methods for e.g. testEmptyNew(), testEmptyExisting.

Patch and interdiff attached.

Nice work @bgilhome! I took it for a manual test drive

1. When adding a new field and setting IEF complex as the widget, the empty mode setting does not appear at first. It only shows up once you save the widget settings for the first time by pressing "Update". I suspect a default value problem?

2. On a multifield widget if the default is 'new', when you reference an existing one, as well as adding the existing one it automatically opens up an 'add new form'. This is visually very confusing and not what you expect (especially if the add new form is big). I think we should consider opening the add new form only if the field is empty. Once a user has added one, they can be given the standard 2 buttons to choose from.

3. On a multifield widget if the default is 'existing', when you reference an existing one it is added correctly, and it's good that the form to add further ones is open automatically. But it's bad that the previously added one still shows up as already selected in this further form.

4. The summary message "For empty fields" and all the variable and method naming is based around these forms only being open if the field is empty. But that is not and should not be how it works on multifields, so there's a lot of rewording/renaming needed.

Hi guys,

I tried to apply latest patch but had difficulties with latest version of drupal 8... Added the schema file and applied a couple of rejected updates by hand and somehow it worked ! Thank you for this patch, it should be added to the module by default as it makes sense to search for existing references before creating a new one.

One issue I have is the autocomplete size limiting list to 10 items... There is a patch in d7 but could not find a way to integrate it on d8.

This would be a great improvement.

FYI: There is also an approach to have pretty much the same functionality with entity browser: Seamless entity reference autocomplete integration [#2772279]. Through "Select content" you can add a node form in entity browser ending up with almost the same UI and functionality. Unfortunatly, like here, there hasn't been much work on that issue recently.

edit: for #23 to work you need 1.x-dev#dbfc93f (from 2016)

Patch flying in with a straight rebase. Hello testbot!

Re: 'Composer error.' test result, see #3065769: Default testbot configuration of 8.8.x-dev + PHP5.6 always fails

Patch [#27] may need a reroll. Not applying clean for me.

Took a look at the patch and attempted to go through it - the only section that still needs to change (other than for test) is this part:
- $hide_cancel = FALSE;
- // If the field is required and empty try to open one of the forms.
- if (empty($entities) && $this->fieldDefinition->isRequired()) {
- if ($settings['allow_existing'] && !$allow_new) {
+ $hide_cancel = $switch_mode = FALSE;
+
The other lines seem to be added already. But even manually adding that section didn't seem to work.

Just jumping in here with a re-roll of geek-merlin's patch for latest version. Tried providing an interdiff file but it always came out blank so must have messed something up somewhere.

Rerolled the patch again for this against the 8.x-1.x branch with an interdiff.

I think that this patch breaks things with commerce products and its product variation inline form... I have the "add product" form always opened when clicking edit existing product variation, and cancel is not there for add new variation...

Marked #2547837: Switching the order of buttons: add new <--> add existing duplicate. It'd be nice to credit @bisonbleu here, if possible.