Cannot select display of view in default value - possible regression

Tried to regenerate the issue from the given scenario, not getting the issue in D10.2.6 with PHP8.3.
Attaching screen-recording for reference : Click to see

Hi @maxilein. Thanks for the report. I reproduced easily. Not able to set a default value. Lots of console logs and db logs and a WSOD on save. Ouch! Clearly there's extreme bugginess with setting a default value.

I have to say I'm very confused as to how the patch https://www.drupal.org/files/issues/2023-08-21/3381787.patch would fix this. That patch sets a handler on the storage, but the handler is related to the field config, not the field storage. So I'm confused.

I think Major is the right priority for this. I don't know that it's a true regression since beta7 had similar (if no identical) problems setting a default value.

I have success with the defaults after updating from beta7 to beta8, but I still have the 3381787.patch applied.
Below is the code after it's applied. While debugging I noticed that the 2nd function is never hit. Which is why applying the patch works.

If remove the patch I get an error. If I move the 'target_type' => 'view' into the 2nd function and delete the first, I get an error.

Also the 2 functions aren't the same, which I though when I glanced over them:
defaultStorageSettings()
defaultFieldSettings()

  /**
   * {@inheritdoc}
   */
  public static function defaultStorageSettings() {
    return [
      'target_type' => 'view',
      'handler' => 'default:view',
    ];
  }

  /**
   * {@inheritdoc}
   */
  public static function defaultFieldSettings() {
    return [
      'force_default' => 0,
      'allowed_views' => [],
      'allowed_display_types' => ['block' => 'block'],
      'handler' => 'default:view',
    ] + parent::defaultFieldSettings();
  }

After getting the WSOD + error, when I go back to the Manage fields screen I see the following error. I'm not sure if it's related.

Deprecated function: str_contains(): Passing null to parameter #1 ($haystack) of type string is deprecated in Drupal\Core\Entity\EntityReferenceSelection\SelectionPluginManager->getInstance() (line 45 of core/lib/Drupal/Core/Entity/EntityReferenceSelection/SelectionPluginManager.php).
Drupal\Core\Entity\EntityReferenceSelection\SelectionPluginManager->getInstance(Array) (Line: 101)
Drupal\Core\Entity\EntityReferenceSelection\SelectionPluginManager->getSelectionHandler(Object, Object) (Line: 97)
Drupal\Core\Entity\Plugin\Validation\Constraint\ValidReferenceConstraintValidator->validate(Object, Object) (Line: 202)
Drupal\Core\TypedData\Validation\RecursiveContextualValidator->validateConstraints(Object, '0000000000000ee20000000000000000', Array) (Line: 154)
Drupal\Core\TypedData\Validation\RecursiveContextualValidator->validateNode(Object, Array, 1) (Line: 106)
Drupal\Core\TypedData\Validation\RecursiveContextualValidator->validate(Object, NULL, NULL) (Line: 93)
Drupal\Core\TypedData\Validation\RecursiveValidator->validate(Object) (Line: 132)
Drupal\Core\TypedData\TypedData->validate() (Line: 307)
Drupal\Core\Field\FieldItemList->defaultValuesFormValidate(Array, Array, Object) (Line: 377)
Drupal\field_ui\Form\FieldConfigEditForm->validateForm(Array, Object)
call_user_func_array(Array, Array) (Line: 82)
Drupal\Core\Form\FormValidator->executeValidateHandlers(Array, Object) (Line: 275)
Drupal\Core\Form\FormValidator->doValidateForm(Array, Object, 'field_config_edit_form') (Line: 118)
Drupal\Core\Form\FormValidator->validateForm('field_config_edit_form', Array, Object) (Line: 593)
Drupal\Core\Form\FormBuilder->processForm('field_config_edit_form', Array, Object) (Line: 325)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 73)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 627)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 181)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 704)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

I'm working on creating a new website. And today, for the first time, I downloaded and installed the Viewfield module for this site.
As described above, I encountered two errors:
Deprecated function: str_contains(): Passing null to parameter #1 ($haystack) of type string is deprecated Drupal\Core\Entity\EntityReferenceSelection\SelectionPluginManager->getInstance() (line 45 of \core\lib\Drupal\Core\Entity\EntityReferenceSelection\SelectionPluginManager.php)
TypeError: uasort(): Argument #1 ($array) must be of type array, null given in uasort() (line 65 of \core\lib\Drupal\Core\Entity\EntityReferenceSelection\SelectionPluginManager.php).

I found that there is no patch in the release of viewfield 8.x-3.0-beta 8 https://www.drupal.org/project/viewfield/issues/3381787#comment-15199519
The viewfield 8.x-3.x-dev 8 May 2024 development release does not have this patch either.

I applied this patch manually by adding a line
'handler' => 'default:view',
and it helped me.
The fix is working, but it has not yet been applied to any release version.

At the moment, it's better than not working at all!

I just opened an MR that I think addresses the bug.

I'm honestly pretty new to this module and haven't used it a ton, but it seems like we are doing things in field settings that might be more appropriate as handler settings for a custom entity reference selection handler. The root of this bug seems ot be that the default selection handler is being run even though it hasn't been configured properly and is (completely?) useless for us. The field widget is doing a lot of things that the selection plugin might be more appropriate for.

For now though just updating the settings form as in the MR should be completely undisruptive and seems to fix things.

Note that I'm seeing a core bug surface: #3302838: Querying with NULL values results in warning mb_strtolower(): Passing null to parameter is deprecated

So if you get Deprecated function: mb_strtolower(): Passing null to parameter #1 ($string) of type string is deprecated in Drupal\Core\Config\Entity\Query\Condition->compile() (line 39 of /var/www/html/core/lib/Drupal/Core/Config/Entity/Query/Condition.php) when testing this out.

Great that you're on the ball at least, @danflanagan8 :-)

I spent some time yesterday looking a the SelectionPluginManager to see how my adding 'handler' => 'default:view' to the storage (default) settings but not the field (default) settings makes the problem go away and I really didn't get far.

The $base_plugin_id parameter to SelectionPluginManager->getPluginId() is sometimes NULL because the instance created by SelectionPluginManager->getInstance() is sometimes constructed with an $options array in getSelectionHandler (either an empty array or the contents of 'handler_settings' from the field definition) without a 'handler' key, which should be the field definition's 'handler' setting. The handler is obviously required, but somehow isn't always present.

It seems this happens when the SelectionPluginManager is called in the ValidReferenceConstraintValidator (phew, we're really Enterprising here)

In the working case (i.e. field settings page loads), 'handler' and 'handler_settings' are set

Drupal\field\Entity\FieldConfig
 ...
  settings => [
    "force_default" => false
    "allowed_views" => ...
    "allowed_display_types" => ...
    "handler" => "default:view"
    "handler_settings" => []
  ]
  ...

but in the non-working case (selecting a view from the dropdown) they are not

Drupal\field\Entity\FieldConfig
 ...
  settings => [
    "force_default" => 0
    "allowed_views" => ...
    "allowed_display_types" => ...
  ]
 ...

This comment turned out to be a bit of a stream-of-consciousness, but I wanted to share my poking around.

@sthomen, thanks for adding those thoughts!

The MR I opened has the essential function (though it's not obvious!) of assuring that `target_bundles` on the handler settings gets set to NULL rather than an empty array. NULL means that anything is allowed whereas an empty array means that nothing is allowed (even though views don't have bundles!).

I suspect that having `handler_settings` itself explicitly set to an empty array as you saw in your testing has the same effect. There's probably two arrays getting +'d somewhere.

If you ave time to test out the MR, I'd really value your review. Cheers!

This looks like a good enough solution to me, however there seems to have cropped up some nits not directly related to the change;

- The AJAX response contains an extra optgroup around the displays, this is only cosmetic but still might be worth looking at

- I saw a couple of JS errors from disable-form-elements.js where doesn't seem to take into account that an ajax instance in Drupal's list might be null. In my experience this happens when an ajax trigger has been updated. Just checking for the instance being null should be sufficient. I would say this should not be fixed in this MR since it really is unrelated.

Hi @sthomen

The optgroup appears to be by design in ViewfieldWidgetSelect::ajaxGetDisplayOptions

I noticed and ignored that console log too. I'm still seeing it when I install beta7 though. I wonder if It's something I introduced while trying to do D10 compatibility. See #21 and #22 on #3299434: Automated Drupal 10 compatibility fixes

I'll open up a new issue that handle that fix.

If you (or someone else) gives the MR an RTBC I'll put out a new release.

Update: JS issue created. #3452741: disable-form-elements.js reads property on null

The optgroup appears to be by design in ViewfieldWidgetSelect::ajaxGetDisplayOptions

Yikes! It's mashing together markup strings, I thought we were past that by now :-)

This all looks good to go to me. It'd be great to have @jannakha look too since they seemed to have success with the handler being set in defaultFieldSettings but I'll go with RTBC so we can move on.

Thanks for the work on this one, @sthomen!

Should be in beta9.