Trying to access array offset on value of type null in EntityBrowserElement valueCallback

I can confirm that #2 patch solved the problem.
Thanks jcisio.

Yes, this is needed for PHP8 compatibility.

I see this pattern being used a lot in Drupal core's valueCallback() methods, including at https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Render%21.... Is there an open issue for fixing those in Drupal Core that you could help point to?

This looks to be the actual fix comparing against other core valueCallback() methods.

Well, patch from #6 does not fix the issue because $input is === NULL and not FALSE, so it does not hit the early return

Patch from #2 fixes the warning

both above patches are not working for Drupal 9.2.0 with Entity Browser 8.x-2.6

I´m still getting the below with or without patch.

Notice: Undefined index: drupalSettings in Drupal\entity_browser\Plugin\Field\FieldWidget\EntityReferenceBrowserWidget::processEntityBrowser() (line 462 of modules/contrib/entity_browser/src/Plugin/Field/FieldWidget/EntityReferenceBrowserWidget.php).
Notice: Trying to access array offset on value of type null in Drupal\entity_browser\Plugin\Field\FieldWidget\EntityReferenceBrowserWidget::processEntityBrowser() (line 462 of modules/contrib/entity_browser/src/Plugin/Field/FieldWidget/EntityReferenceBrowserWidget.php).
Warning: key() expects parameter 1 to be array, null given in Drupal\entity_browser\Plugin\Field\FieldWidget\EntityReferenceBrowserWidget::processEntityBrowser() (line 462 of modules/contrib/entity_browser/src/Plugin/Field/FieldWidget/EntityReferenceBrowserWidget.php).

Those notices and warning seem unrelated

The first patch works for me.

The problem is due to $input being null.

I'd like to see a fix like this:

    if ($input === FALSE || $input === NULL) {
      return $element['#default_value'] ?? [];
    }

I'm not sure the exact right status of this, but it's not "RTBC" anymore :)

I just tried the MR 7 patch on our site (I think it was successful) -- our situation also involves excessive levels of referencing, but with ECK bundles, not paragraphs.

We have ECK entities embedded in WYSIWYG fields, using entity_embed and embed_button -- and entity_browser gets used along the way, too. We get the notice described in this issue (Trying to access array offset on value of type null in...) after selecting an entity to embed -- in other words, when we're back in the smaller modal/dialog, right before getting back "into" the WYSIWYG field, if that makes sense (screenshot attached -- the lack of a thumbnail of the selected entity in this dialog is a separate issue, as far as we know -- something about a limitation of how ECK works with our other entity/embed modules).

We only get the notice when initially embedding the entity -- if I double-click on a previously embedded entity (in WYSIWYG), there's no notice.

I think our situation is actually quite similar to the original author, except that in our case, the extra levels of referencing come from ECK, not paragraphs. The notice only happens when embedding an ECK entity where there's an entity browser within an entity browser, basically -- like, we have a few "simpler" ECK bundles that also get embedded in WYSIWYG fields via embed buttons, but they don't trigger notices in dblog -- only the situations where we're three (or four??) levels deep.

-------
I'm going to try to explain -- I hope it makes enough sense! (oh and, I know this setup is horribly convoluted; all I can say is, we sure wish it weren't like this 😖)

• ECK type: media_embed
• Two bundles: image, video
• Each bundle has an entity reference field (targets media entities of type "image" and "video", respectively), a caption field, and a text/option list field we don't care about right now. (Yes, the ECK media_embed bundles have the same machine names as the media bundles, image/video. Oh well.)
• So, using the (ECK) media_embed > image bundle, as an example...
• The "image" ECK bundle > default form mode uses an entity browser for selecting image media entities (media_embed.image.field_image).
  • The entity browser it uses is: image_embed_library.
  • This entity browser has two plugins: view, and "dropzonejs_media_entity" for adding new image media entities to this field.
• The default text editor has embed buttons, including an image embed button, which embeds (ECK) media_embed > image entities. This image embed button uses an entity browser to add (ECK) media_embed > image entities.
  • The entity browser it uses is: image_embed
  • This entity browser has one plugin: entity_form
• !! So !! Putting it all together...
  1. You're in a WYSIWYG field, you click the image embed button.
  2. You get a modal with the image_embed entity browser, which contains an entity form to create a new (ECK) media_embed > image entity.
  3. In that form is an entity reference field to add an (media) image to your new ECK entity, and this entity reference field uses the image_embed_library entity browser.
  4. You select or upload an image for the entity reference field -- after you select something, you're still in the "image_embed" entity browser modal, with a preview of the image you selected, a caption field, and the text/option list field.
  5. You click "insert."
  6. You're in a smaller dialog now -- it's the final dialog for the embed button (the one in my attached screenshot), where you get to pick an alignment option and then click "Embed."
  7. ^^Right now is when the notice happens.

-------
With the MR 7 patch, the notice is gone. I don't know if there are other issues, but the notice is gone, so I figured I'd share my story.

Patch fixes the notice, yet the image is (still) gone.

Our setup is a block with paragraph which has an image field, within layout builder.

Selecting/uploading goes fine, but when we want to add another delta, the second delta appears, but the uploaded/selected image is gone on the first delta.

This started after updating to D9.2.9 recently - coming from latest D8, where it worked perfectly. Might be LB related, but not sure of course.

Note: using that paragraph on a node, the default value of the image is fine, so it's in combination with LB.

update The notice might be a red herring when it comes our problem, revering to 8.x-2.5 and still the same problem, so sorry for the noise.

Attaching patch created from MR #7 to support Composer based workflows.

In my case, the Remove button was not working as expected an patch #17 (or MR #7) solved it.

Tested and merged to 8.x-2.x.