Contrib.social

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

Open on Drupal.org →
Created on 7 January 2020, over 5 years ago
Updated 24 April 2024, over 1 year ago

Hi,

I am having problems with entity browser and layout builder. In layout builder I add a custom block with several referenced entity fields using the entity browser to select entities and at some point the entity browser is not showing when editing the block and trying to change the referenced entities.

Steps to reproduce:

  1. Create a custom block type with two referenced entity fields and select an entity browser to select the referenced entities for each field
  2. Create a content with layout builder manage display
  3. In the layout view of the content, add a custom block of the previous custom block type, select entities with the entity browser modal display for the two fields and save de block
  4. Edit the custom block and try to remove the selected entites of the two fields and select new entities
  5. At some point it is not possible to add or remove entities and the entity browser modal display is not showing any more

Regards

🐛 Bug report
Status

Needs work

Version

2.6

Component

Field widget

Created by

concano

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment over 1 year ago →
    🇺🇦Ukraine david-b Kropyvnytskyi

    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

  • Comment over 1 year ago →
    🇵🇰Pakistan alinouman

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

  • Merge request !81Issue #3104901: Entity Browser used in a entity referenced field of a layout builder custom block is not working → (Open) created by acbramley
  • Comment 3 months ago →
    🇦🇺Australia acbramley

    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?

  • Pipeline finished with Failed
    3 months ago
    Total: 588s
    #520291
  • Comment about 2 months ago →
    🇺🇸United States cboyden

    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.

  • Status changed to Needs review 26 days ago
  • Comment 26 days ago →
    🇩🇪Germany Anybody Porta Westfalica

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

  • Comment 22 days ago →
    🇺🇸United States dsnopek USA

    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

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024