entity browser crashes: 'Used entity browser selection display does not support preselection'

This happens because of misconfiguration. You are trying to use preselection with a plugin that does not support it.

It was done on purpose. We'd detect misconfiguration on entity browser creation time, but that is unfortunately not possible. When user is creating entity browser you can't predict in what kind of situations it will be used and this is the best solution that we've figured out so far.

Another option would be to silently ignore preselection, but that could lead to data loss. I think that failing loudly is still better than that.

I am open for ideas of course.

- B. User creates an EB, then uses it in a field widget, and then goes back to the EB and changes the configuration there in a way that's not compatible.

That'd be me. Just ran into this issue when trying to jigger the entity browser for a photo upload form into a more usable state. Instead it became a white screen of death state.

Ditto. Certainly surprised me that this would crash the node edit form for the type using the "misconfigured field"...I'm trying to decipher just what "Used entity browser selection display does not support preselection" even means, can someone interpret the error message for me in layman's terms? What specifically isn't supported that I was able to select or set that the module now sees it as "misconfigured" for the field?

If it's not possible to prevent the user from creating an entity browser that induces this error in the first place, you should at least report it in a more friendly way. The current method of throwing an uncaught exception is very bad UX. Show the error message at the top of the node edit page and include more details about what settings are wrong. Perhaps even include a direct link to the settings for the EB instance.

This wasted a few hours for me yesterday. At the very least you should put in an intelligible exception message because right now it makes no sense at all. Actually my workaround for most of the day was to just comment out the line that throws the exception in checkPreselectionSupport, and that worked fine for me.

And that there has to be an article entitled "Common Pitfalls When Configuring Entity Browser in Drupal 8" is absurd.

Marking as a bug because exceptions are never an expected behaviour
Marking as major because it "Trigger a PHP error through the user interface, but only under rare circumstances or affecting only a small percentage of all users, even if there is a workaround.". See https://www.drupal.org/node/45111.

This issue was posted 2 years ago, and was marked as a major bug 7 months ago.

1. Is it ever going to be fixed?
2. At the very least you should add a link to some kind of documentation when that error occurs.

I've also noticed that there was not a single commit in 4 months, the module page directs to an archived github repository, the roadmap refers to version 1.0 (and not the current 3.0) - Was this module silently abandoned?

Hi @eyal-shalev - we sprinted on Entity Browser issues last week at Drupalcon Nashville and didn't have enough time (or people) to get to this issue. Entity Browser issues will still be worked on based on priority and age (by created date), so yes this will get fixed. One thing that would help push this issue forward is a patch that prevents mis-configuration of Entity Browsers, or that handles this error in a more human-readable way (hide the widget and show a message, for example).

This module has not been abandoned, but many team members have been focusing on pushing core Media forward which takes up a lot of our time. Recently we've been relying on the community to help us out and get patches into a reviewable state, but I want to dedicate more of my time to the project to make sure the queue stays manageable and the module is usable. I'm a co-maintainer and work on Drupal core so my time is often split between a lot of tasks.

I dug into this problem an found the following:

The Drupal\entity_browser\Element\EntityBrowserElement wants to check whether the SelectionDisplay supports Preselection, but the method checkPreselectionSupport just throws this Eception, that ist not handled, if the Selection display does not support Preselection.

modules/contrib/entity_browser/src/Element/EntityBrowserElement.php Line 147

    // Propagate selection if edit selection mode is used.
    $entity_browser_preselected_entities = [];
    if ($element['#selection_mode'] === static::SELECTION_MODE_EDIT) {
      $entity_browser->getSelectionDisplay()->checkPreselectionSupport();

      $entity_browser_preselected_entities = $element['#default_value'];
    }

modules/contrib/entity_browser/src/WidgetSelectorBase.php Line 132

  /**
   * {@inheritdoc}
   */
  public function checkPreselectionSupport() {
    if (!$this->getPluginDefinition()['acceptPreselection']) {
      throw new ConfigException('Used entity browser selection display does not support preselection.');
    }
  }

I think that the 'checkPreselectionSupport'-Method should return a boolean, and should noct throw the Exception. The caller must check the answer, and react respectively.

I will provide a patch for this shortly.

This method is called only once in the module, so I don't expect any sideeffects

Here comes a patch as a starter, at least the entity_form is not crashing anymore, and a warning messages is displayed, that the browser widget is not configured correctely.

The Javscripts-tests fail on my local system, but as unpatched version is also failing, I consider not a part of this issue.
OK it is my test environment!

To get rid of the warning I think the EntityReferenceBrowserWidget may not the option 'edit selection' when the browser does not support this.

+++ b/src/SelectionDisplayBase.php
@@ -130,9 +129,7 @@ abstract class SelectionDisplayBase extends PluginBase implements SelectionDispl
-    if (!$this->getPluginDefinition()['acceptPreselection']) {
-      throw new ConfigException('Used entity browser selection display does not support preselection.');
-    }
+    return $this->getPluginDefinition()['acceptPreselection'];

This would be a BC-breaking change... Not sure many people rely on this method, but if we can avoid breaking BC, it would be ideal.

IMHO the best approach for this would be to prevent a configuration that we know will not work from happening in the first place. I think this could be done in two steps:
1) When building the field widget settings form, loop over all browsers and only include as options those that support pre-selection
2) When saving an existing browser, if it supported pre-selection previously and after it doesn't, fail validation if it is being used in a field widget that would be broken with the new configuration.

Does that make sense?

@marcoscano We could catch the exception in the UI and show a warning, but keep the API method the same right?

Breaking BC is an issue, I was thinking of catching the exception an reacting appropriately, but my personal feeling is that Exceptions should be used for rather exceptional states. Here is a capability of the object queried, which is not exceptional, but a rather normal process. Querying this with a simple 'if' statement shows the normality of this process.

Maybe we could introduce a method like SelectionDisplayBase::supportsPreselection() that is querying this capability and leave the checkPreselectionSupport as was and mark it deprecated.

As the module is still in alpha-phase, an api-change should not be completely forbidden.

For my personal interest I already modified the widget, And there I think it's even more approriate to query the capability instead of catching an exception.

The EntityBrowserElement then should implement something like:

  /**
   * Get selection mode options.
   *
   * @return array
   *   Selection mode options.
   */
  public static function getSelectionModeOptions($entity_browser_id = null) {
    $options = [
      static::SELECTION_MODE_APPEND => t('Append to selection'),
      static::SELECTION_MODE_PREPEND => t('Prepend selection'),
    ];

    if ( $entity_browser_id ) {
      $entity_browser = EntityBrowser::load($entity_browser_id);
      if ( $entity_browser->getSelectionDisplay()->checkPreselectionSupport() )
        $options[static::SELECTION_MODE_EDIT] = t('Edit selection');
    } 
    return $options;
  }

1) When building the field widget settings form, loop over all browsers and only include as options those that support pre-selection

This will need some JS-actions - unfortunately I could not help there, my JS-skills are not good enough

2) When saving an existing browser, if it supported pre-selection previously and after it doesn't, fail validation if it is being used in a field widget that would be broken with the new configuration.

If s.b. gives me a hint, how I can validate the field widget (sorry, never written a widget yet) I would happyly work on this issue (Probably a follow-up?)

@samuel.mortenson

We could catch the exception in the UI and show a warning, but keep the API method the same right?

I thought about this too, but then realized that this wouldn't even be necessary. If we don't expose to the UI options that will break things, we would never reach the mis-configured scenario through normal use of the UI. (which is what we are trying to improve here: the site-builder experience when experimenting with the module)

@mmbk

As the module is still in alpha-phase, an api-change should not be completely forbidden.

Unfortunately the module has a stable release (8.x-1.4), and the 2.x branch is supposed to be BC with the 1.x branch, if I recall correctly.

I thought about this too, but then realized that this wouldn't even be necessary. If we don't expose to the UI options that will break things, we would never reach the mis-configured scenario through normal use of the UI.

If the exception is not catched, the exception is useless. So we don't even need to check the condition, assuming that everything will work correctly. Probably it would do less harm, passing the selected items to a selectionDisplay, that does not support this mode and ignores the list. I'm not sure that this is a good idea.

The widget will still need a method to decide if the SelectionDisplay supports the SELECTION_MODE_EDIT, and here I still think querying a method that returns a boolean value is the better way. Because we have to know if the mode is supported, and in this way it is expressed explicitly. (Sorry I can't explain it better in the moment - I need to practice my englsh)

Ran into this when loading the entity-add form for ECK for a custom entity bundle that used entity browser for an image field. The patch resolves the issue for me.

This problem happens in Entity Browser 2.x too.

The patch in #18 fixes the issue for version 8.2-dev

Here's an updated patch

• Leaves checkPreselectionSupport alone and marks it deprecated in SelectionDisplayBase, SelectionDisplayInterface. This should handle concerns about BC.
• Adds new method supportsPreselection to SelectionDisplayBase, SelectionDisplayInterface as mmbk recommends in #21.
• Changes the check to use new method
• Adds validation on the field widget form to prevent further misconfiguration.

On node form:

On field widget config:

Failure was random, setting back to Needs Review.

Adding test coverage.

Fixing test coverage. Last patch failed because links that start/admin/ etc doesn't work on testbot. Drupal is installed in a subdirectory, so it would have to be /subdirectory/admin/ etc. I changed the assertion to use pageTextContains to get around this difference. The most important thing is that the error message is displayed.

Nice work, the changes are working as expected.
- The field-widget forbids to use an entity_browser w/o selection display, when SELECTION_MODE_EDIT is wanted. I htink the message shown is clear enough for the sidebuilder to take the appropriate actions.

However, a new problem arose.

If you've added an entity browser with preselection to a form successfully and change the entity browser later, you can enter the form (this was not pssible originally) . The form and the message concerning the configuration problem ist displayed.
In the the step when you try to open the entity browser, the browser crashes again.

The website encountered an unexpected error. Please try again later.</br></br><em class="placeholder">Drupal\Core\Config\ConfigException</em>: Used entity browser selection display cannot work in combination with settings defined for used selection widget. in <em class="placeholder">Drupal\entity_browser\Form\EntityBrowserForm-&gt;isFunctionalForm()</em> (line <em class="placeholder">202</em> of <em class="placeholder">modules/entity_browser/src/Form/EntityBrowserForm.php</em>). <pre class="backtrace">Drupal\entity_browser\Form\EntityBrowserForm-&gt;buildForm(Array, Object)
call_user_func_array(Array, Array) (Line: 518)
Drupal\Core\Form\FormBuilder-&gt;retrieveForm(&#039;entity_browser_image_browser_form&#039;, Object) (Line: 275)
Drupal\Core\Form\FormBuilder-&gt;buildForm(&#039;entity_browser_image_browser_form&#039;, Object) (Line: 93)
Drupal\Core\Controller\FormController-&gt;getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber-&gt;Drupal\Core\EventSubscriber\{closure}() (Line: 582)
Drupal\Core\Render\Renderer-&gt;executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber-&gt;wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber-&gt;Drupal\Core\EventSubscriber\{closure}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel-&gt;handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel-&gt;handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session-&gt;handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle-&gt;handle(Object, 1, 1) (Line: 99)
Drupal\page_cache\StackMiddleware\PageCache-&gt;pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache-&gt;handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware-&gt;handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware-&gt;handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel-&gt;handle(Object, 1, 1) (Line: 693)
Drupal\Core\DrupalKernel-&gt;handle(Object) (Line: 19)

The status with patch #34 is so much better, than the original. A sitebuilder should know what to do next, to get rid of the warning messages.

The situation where the exception is thrown, is rather exotic. Only for testing here I changed the browser back to 'No selection display'. I doubt that it will happen to often. That's why I think we shoul handle that eception in a follow-up, and consider this done.

The exception is similar to the checkPreselectionSupport() Exception. The exception is used as flow control. The function should return a boolean that can be tested by the caller.

EntityBrowserForm line 195ff.

 /**
   * Check if entity browser with selected configuration combination can work.
   */
  protected function isFunctionalForm() {
    /** @var \Drupal\entity_browser\WidgetInterface $widget */
    foreach ($this->entityBrowser->getWidgets() as $widget) {
      /** @var \Drupal\entity_browser\SelectionDisplayInterface $selectionDisplay */
      $selectionDisplay = $this->entityBrowser->getSelectionDisplay();

      if ($widget->requiresJsCommands() && !$selectionDisplay->supportsJsCommands()) {
        throw new ConfigException('Used entity browser selection display cannot work in combination with settings defined for used selection widget.');
      }
    }
  }

Called only once, in the same saource

  public function buildForm(array $form, FormStateInterface $form_state) {
    // During the initial form build, add this form object to the form state and
    // allow for initial preparation before form building and processing.
    if (!$form_state->has('entity_form_initialized')) {
      $this->init($form_state);
    }

    $this->isFunctionalForm();

+++ b/src/SelectionDisplayInterface.php
@@ -65,10 +65,21 @@ interface SelectionDisplayInterface extends PluginInspectionInterface, Configura
    *
+   * @deprecated
+   *  Use ::supportsPreselection instead
+   *
    * @throws \Drupal\Core\Config\ConfigException
    */

Message should be on the same line and end with a ".". core guidelines are to always specify when it has been deprecated and when it will be removed, but we don't know that yet.

Maybe also add a @trigger_error() in the methods, so that anyone calling that in test will be notified?

Thanks, updated.

Rerunning test on #38. It was a random failure.

Committed! Thanks!