Seamless entity reference autocomplete integration

I think we should try to get the updated for 8.x-2.x.

This patch adds one more feature - "Advanced search" link at the end of autocomplete suggestions. When clicked, it opens entity browser.

I added preview improvement. So now, when something is selected you can setup preview of it in widget configuration. How it looks like:

Re-rolled against latest 2.x + fixed an issue when copy/paste something in the autocomplete field (this issue was introduced in patch in #31).

Reviewed and tested.
Drupal 10.3
MR was applied without any issue.
Suggest adding MR
thanks

Minor improvement: The preview remove button form #name was not always unique.

Patch in #34 gave me JavaScript issues on Drupal 10.4.6. event.target.preventDefault(); was being called where event.target was undefined. Appeared an issue with the order of JavaScript being loaded. Added small adjusment to make sure the JavaScript is loaded after autocomplete is initialized.

This functionality would still be really fantastic and a great improvement for Drupal!

Not being forced to decide for the easy and quick autocomplete widget, if you know the label of an entity, but also having the option to alternatively use entity browser alternatively on the same widget, would be absolutely best for more complex use-cases.

On top it would be a dream to have the option to create a new or edit the referenced entity in a modal, but that's a different topic. Having all that would make things really complete and useful!

PS: Let's switch to using a MR instead of patches! Anyone else interested in pushing this over the finish line?

This should be it! Please review!

Tests fail because of 🐛 Fix arguments for tests Active .

A few things are still not perfect.

Based on a very quick test, some first feedback:

* Doesn't seem to work at all on cardinality 1 fields, I'd want to use this for the paragraphs_library paragraph type, which is one of those. I get a button
* should use smaller button classes on Claro/gin, they seem huge.
* add another item and select button to open entity browser are IMHO pretty confusing and not a great user experience. maybe the the entity browser button could be on top, maybe both small next to each other with some guidance on which does what?
* edit doesn't seem to use the same dialog system as the regular entity browser widget

(we have the widget pretty heavily customized in our project, with custom edit/delete icons on top of the previews instead of buttons, so I'm not 100% sure if anything affects that, didn't test on plain claro yet)

@rp7

Patch in #34 gave me JavaScript issues on Drupal 10.4.6. event.target.preventDefault(); was being called where event.target was undefined.

That is, because there is no event.target.preventDefault(). There is only event.preventDefault(), see https://developer.mozilla.org/en-US/docs/Web/API/Event/preventDefault.

Manually adjusting the weight in the library is not recommended and messes with code execution timings, which leads to frustrating debugging sessions. Please avoid it.

@berdir, thanks for the feedback!

Doesn't seem to work at all on cardinality 1 fields, I'd want to use this for the paragraphs_library paragraph type, which is one of those. I get a button but no autocomplete field

This sounds weird! I have only tested it with target entity type being "node". Could you test the latest MR, if that is still the case now?

should use smaller button classes on Claro/gin, they seem huge.

Definitely. A Colleague of mine could possibly fix up the styling.

add another item and select button to open entity browser are IMHO pretty confusing and not a great user experience. maybe the entity browser button could be on top, maybe both small next to each other with some guidance on which does what?

Ok, I'll take a look on Monday.

edit doesn't seem to use the same dialog system as the regular entity browser widget

Hm, could not reproduce this behavior, but maybe I misunderstand. Could you elaborate

Generally feel free to do some final touches here! This was quite the pain to finalize.

I think the main problem is, that this Widget extends "EntityReferenceAutocompleteBrowserWidget" instead of "EntityReferenceBrowserWidget", and therefore the implementation differs enormously from the original widget.

But this might have a reason, and I am really thankful that this MR was already this far in development. Thanks all! 🎉

Anyway, I think this can get reviewed now. Final touches should still be added. Unsure if we can provide test coverage....

Thanks @grevil! Great (and really hard) work. Current status attached as static patch.

@thomas.frobieter, please finalize the styling and button placement based on comment #45.

Testing with plain core + paragraphs_demo, I can confirm that things around cardinality 1 were either fixed or are broken due to customizations in our project, will need to check that. I did run into another issue though, something is off with the ajax replacement selector, resulting the whole element being replaced:

(to reproduce, install paragraphs_demo, switch the from library paragraph to use this with preview and button, then pick an item from the autocomplete selection)

Another thing I noticed is that there seems to be a replace button but no setting for that (with cardinality 1). The button also seems broken with an ajax error, but could also be related to the bug mentioned above). Seems pointless to have that, as the regular button is always visible and does the same, the code here might be older than the replace feature and might just not account for that?

Also, the show delete button setting does nothing on multi-cardinality because core now provides one of those by default I assume.

And definitely needs some UI improvements as mentioned before. Unsure how it should look, and I tend to forget how ugly the default look of entity browser is too, but this is worse. It looks like all elements (textfield + preview + buttons) are just all stuffed together with display: inline-block, so if you have a very short preview, it's just directly after the textfield, and if it's longer, some buttons are after it, some are on the next line.

Hey @berdir, the paragraphs incompatibility is fixed now! There was also an issue with the triggering elements on ajax callback, not being identified correctly (related to 🐛 Wrong triggering element on the form submit after an ajax callback call Active ) that is fixed as well.

Another thing I noticed is that there seems to be a replace button but no setting for that (with cardinality 1). The button also seems broken with an ajax error, but could also be related to the bug mentioned above). Seems pointless to have that, as the regular button is always visible and does the same, the code here might be older than the replace feature and might just not account for that?

There is a bug, where entity_browser still provides the old target id even when we already selected a new entity through the browser. The "normal" Entity Browser Widget fixed that through creating a "replace" button, which basically removes the old entity first and then opens the entity browser to select a new one. But for some reason, there is a setting for this in the other Widget. This widget does not have this setting, the replace button is always shown when the autocomplete field is filled, otherwise the normal entity_browser button is shown.
Before the last commit both the enity_browser button AND the replace button were shown at the same time. This is now fixed as well.
(Note, that the behavior "[...] removes the old entity first and then opens the entity browser to select a new one", means that closing the entity browser modal, leads to the autocomplete field not being filled anymore, but this happens in the old widget as well and should be fixed in a follow-up issue on both widgets)

Also, the show delete button setting does nothing on multi-cardinality because core now provides one of those by default I assume.

Yes, codewise we only add our own remove button, when the setting is activated AND the cardinality is 1. I guess, we should hide the "remove_button" setting, when the field cardinality is set to > 1.

And definitely needs some UI improvements as mentioned before

Yes definitely! Although I am unsure if this should be done in a general follow-up issue, since the UI of the original Widget is not very nice either.

Ok, @berdir feel free to do another review! Everything except the style should be to your liking now.

Static patch for the time being.

Found 2 more bugs. Static patch attached.

While testing the Widget, I occasionally ran into 🐛 Media Library modal opens randomly on AJAX requests Active .

Not unsetting '_actions' and 'weight' in the callback, seems to fixed it without any seeming regression.

Not unsetting '_actions' and 'weight' in the callback, seems to fixed it without any seeming regression.

This was introduced in #31 FYI: https://www.drupal.org/files/issues/2024-10-10/entity_browser-2772279-31... → by @gugalamaciek.

The first patch didn't contain that part of the code.

A few performance fixes and bug fixes. I haven't tested the "preview_view_mode" setting anymore, it might be broken due to https://git.drupalcode.org/project/entity_browser/-/merge_requests/85/di..., but IMO I would better leave it out completely then running into 🐛 Media Library modal opens randomly on AJAX requests Active again, this widget is already complex enough.

We could re-add the feature in a follow-up issue. (But it might not be broken at all, so we don't have to do anything).

Current MR as a static patch is attached.