Entity Browser used in a entity referenced field of a layout builder custom block is not working

I can replicate this issue. This seems to be broken when the entity form is being displayed in a modal window. My temporary solution (until the modal is working again) is to use iFrame instead of Modal.

I am also running into this, even on version 2.4 of EB, and on version 8.8.4 of Drupal.

In my case, this is happening even with just 1 entity browser field on the block form.

There's also no JS console errors, and the AJAX POST request to open the modal returns a 200 status code. It just... doesn't open the modal.

I confirmed that this was related so something in the upgrade from 2.1 to 2.2. Trying to pin down the exact commit. I'm also using Lightning Media, but I'll try and get a site set up were that's not being used as well.

After lots of debugging, I was able to narrow down the cause of this issue to #3046416: Remove button conflict wrong triggering element, which was released in version 2.2. After reverting the small changes made in that commit, everything works as expected for me, even on the latest 2.4.

Interesting that I can only reproduce the issue when creating/editing a custom "inline" block with Layout Builder. If I add the block content entity outside of layout builder, the entity browser widgets work as expected. The difference between these two is that when a block form is displayed in layout builder, it's set up as an embedded form, so the logic introduced in #3046416: Remove button conflict wrong triggering element must not account for that somehow.

There's two distinct scenarios I encountered, both of which are fixed by reverting that commit:

1. Two entity browser widgets on the same block. When clicking "remove" on the first field, and then pressing the button to select a new entity, the entity browser for the SECOND field is actually launched!
2. One entity browser widget, where the field is REQUIRED. In this case, when you go to remote a previously selected entity and then go to select another, nothing happens. The browser does not open. If you change the field to not be required, then it works fine.

I'll spend some time today trying to fix the logic in that original patch if I can.

RE: my first scenario, a single required EB field where the "select entities" button seems to do nothing after clicking "Remove" on the existing entity... There's also an AJAX message that is set indicating that the EB field is required and cannot be empty, but it's not just being printed anywhere in the layout builder settings tray. You can see it when inspecting the POST request result though.

Reverting the lines that were changed from patch in #3046416: Remove button conflict wrong triggering element related to getEntitiesByTargetId fixes the problem for me. I think those lines may need another look? I don't use entity browser with inline entity form so I'm not sure of the implication.

What is still quite interesting to me is that this seems to only be a problem when using EB within an embedded form like layout builder does. I suspect that there's some other bug somewhere that this exposed.

Hi,

I experienced a similar issue. Entity browser is not showing at all when used in Layout builder.

I am using the file_browser module that provides a pre-made entity browser but even creating a simple entity browser myself doesn't work.

I have a custom block with a File field and I am using an entity browser to select it. It works great when creating a custom block through Structure / Blocks, but not when using Layout builder. I also tried with a media field, doesn't work either.

* My bad, it is working some other JS on anchors was conflicting with it.

Patch in #9 worked for me, thanks!

Patch in #9 also worked for me, thx!

Patch in #9 helped me to fix a problem related with not being able to remove images from blocks inside Layout Builder.

I've got another, similar issue with entity browser inside Layout builder (using Layout Builder modal module).

When creating a brand new block in layout builder that has an entity browser field if I Select an entity and then immediately try and remove it, it launches the entity browser modal again.

This does not happen when adding the same block type outside of layout builder.

I can confirm that #9 fixes the issue for me.

EDIT: However, that then causes another bug when reordering items and then clicking remove triggering the same behaviour.

Ran into issue where $form_state->getUserInput() was null, so here's a fix for that.

Can confirm this is still happening in 2.5

Tried both patches from #9 and #17 but neither worked. I can't add entity references in layout builder.

Also confirming I see this issue in 2.5, and neither patch helped.

What we are using is Layout Builder inline blocks, Acquia Dam, and the layout builder modal module. Using the reference field the entiy browser comes up and you are able to select an image. When you click the choose image button, the modal closes and the widget is not updated. You still see the 'Select image' button and no thumbnail. However, the images are actually added, which you can see if you save the block anyway.

I have tried to see if there is an issue with other image field widgets but it seems to only affect entity browser widgets with the modal. Outside the modal the same widget works perfectly fine.

It's been awhile since I looked at this, and I'd meant to follow up once I had confirmed, but I got tied up and didn't have a chance to revisit, but I think the real issue is the core bug I filed here: #3177977: Form state storage changes in #process callbacks are not cached during form rebuild.

I forget if just adding the core patch I created in that issue resolves the issue in total.

Any chance this is related to https://www.drupal.org/project/entity_browser/issues/2851580 ?

The latest patch there also fixed #2685029 for me which sounds similar, just not specific to layout builder.

Wanted to try a different approach which, in local testing, fixes the problem as well, but not sure how the tests will react.

We also encountered another problem that relates to this in the case of the Inline Entity Form module does not exist on the projects.
I have created a quick patch.
I am not sure, should we merge the source code from #24 and #26.

#17 fixed issue for us in Open Y distro
https://github.com/ymcatwincities/openy/pull/2635

When you have a paragraph within paragraph - Entity Browser doesn't work

#17 fixed it

We have also got same issues.
We have using 2 entity_browser fields in content type.One field exist in paragraph field and another field exist in content type fiield.
When upload file in first field after that other field stop working for upload filed.
i have tried patch #9 for this and issues fixed.
Kindly suggest me which patch is good for use without any new bug.

This conflicts with another change that I committed, which should fix paragraph use cases, don't know about layout builder. Needs a reroll and verification if 8.x-2.x-dev is still affected by this bug.

Experienced a similar issue.

We have a layout builder setup where blocks are configured in a modal window.
One of those blocks contains a node reference field with entity_browser on it.
When trying to delete nodes, the last node would not delete and the entity_browser to add new nodes would pop open automatically after clicking the delete button.
This only occurred when deleting nodes left to right, not when deleting nodes in any other order...
(I have a screen recording of the behaviour, but can only share private)

We tried this on entity_browser 2.6, 2.7, 2.8 and the current dev release. All had the same issue for us.

I read through all of the related issues (10+) tried all of the patches that would apply to both 2.8 and current dev, and non worked for us.
The only patch that fixed our issue was the #17 and #24 here this topic. (didn't try the older ones though)

UPDATE: only #17 works, #24 introduces new issues for us when deleting reference nodes.

Patch #17 looks to work for me, but doesn't work for the current version of the module. Created a patch based on patch #17

#31 works good for me. Thanks david-b for your help.

Rolled #31 into an MR

Confirming I can still reproduce this issue on 2.x HEAD without the patch. Test coverage for this is going to be rough, but I'm not sure if we want to block on that or not?

The code in the MR (built from patch 31) is working for me, it fixes a very tricky issue that we've been wrangling for a while.

Let's proceed with the MR. @cboyden could you take this further maybe, so we can get this fixed?

With the changes in #31, I think that most of the code in EntityReferenceBrowserWidget::formElementEntities() below the call to $this->getEntitiesByTargetId() won't ever run, because if there are any existing items, that function will always be able get them. This is quite a bit of code - I think lines 774 to 833 (~60 lines) become dead code, with only the logic for loading for the first time (lines 833 to 845) still being relevant.

Assuming I'm right about this, then this patch should probably also remove all that unused code, so it isn't there to confuse people reading the code in the future. :-) However, the fact that this makes so much dead code makes me nervous that there is some edge case covered by that code, and removing it will break something? That said, this patch is fixing this problem for me, and I haven't stumbled on whatever that edge case might be yet

Oh thank you so much for MR, fixed the annoying problem with nested modals with Layout builder 🎉

Claude Code says:

Two changes are bundled together:

1. Removes the Inline Entity Form (IEF) special-case. The old code had a carve-out: if the triggering element was an IEF edit-submit button, it would skip the early return FALSE even if the target_id key didn't exist. The new code removes this entirely — now it always checks for the key's existence regardless of what triggered the submit. This simplifies the logic but could be a behavioral change for IEF users. If IEF submissions legitimately don't populate target_id in user input, this would cause getEntitiesByTargetId() to return FALSE where it previously continued.
2. Adds ?: [] null coalesce on getUserInput(). This is a defensive fix — getUserInput() can return NULL, and NestedArray::keyExists() requires an array. This prevents the TypeError referenced in commit cd364ce in this branch's history.

Assessment:

- The null safety fix (?: []) is good and straightforward.
- Removing the IEF workaround is riskier. It may be intentional cleanup (perhaps the IEF issue was fixed upstream), but there's no commit message or issue context explaining why it's safe to remove. If IEF integration is still a supported use case (there are IEF tests in this module), this could be a regression. I'd want confirmation that this was tested with Inline Entity Form before merging.

Also note: This branch diverged much earlier than the others (merge base is 411633f, well behind 8.x-2.x). It carries 17 commits of history that have since been independently applied to 8.x-2.x, and the "Patch 31" commit message suggests this is a long-lived integration branch. Rebasing onto current 8.x-2.x before merging would be wise to confirm no conflicts.

@aprupue, I think the approach to Inline Entity Form in #3480712 is probably better than the one here, and we could adopt that approach here, but first we'd need to know the actual $user_input['_triggering_element_name'] value when the bug fires. Is that something you have?