Problem/Motivation

DER doesn't support OptionWidgets.

Proposed resolution

To make DER inline with ER let's add OptionWidgets for single value target type fields(for simplicity).
This also fixes some nasty bugs in DERItemList and DERItem which I found while fixing this.

Remaining tasks

Review

User interface changes

This patch adds the following widgets:

API changes

Hmmm let me think.

Comments

jibran’s picture

Title: Add OptionWidgets for single value target type DER fields » Add OptionWidgets for single value target type DER fields
larowlan’s picture

  1. +++ b/src/Plugin/Field/FieldWidget/DynamicEntityReferenceOptionsTrait.php
    @@ -0,0 +1,96 @@
    +    return count(DynamicEntityReferenceItem::getTargetTypes($field_definition->getSettings())) == 1;
    

    Neat

  2. +++ b/src/Plugin/Field/FieldWidget/DynamicEntityReferenceOptionsTrait.php
    @@ -0,0 +1,96 @@
    +      list($values[$index]['target_type'], $values[$index]['target_id']) = explode('-', $value['target_id']);
    

    Cool trick

Is there somewhere we're checking the user has access to the entity label? E.g. we don't want to be showing node titles if the node is unpublished and the user doesn't have access. Similar stuff to what we do with formatters. I assume it defers to something in ER in core? But best check because otherwise we might have security issue.

What happens if there are 1000s of nodes and someone (stupidly) uses this? Should we check that in the is available method too? To make sure that people don't bust their site.

jibran’s picture

Issue tags: +Needs manual testing
StatusFileSize
new8.82 KB

Is there somewhere we're checking the user has access to the entity label? E.g. we don't want to be showing node titles if the node is unpublished and the user doesn't have access. Similar stuff to what we do with formatters. I assume it defers to something in ER in core? But best check because otherwise we might have security issue.

From DynamicEntityReferenceItem::getSettableOptions()

    foreach (array_keys($target_types) as $target_type) {
      $options[$target_type] = \Drupal::service('plugin.manager.dynamic_entity_reference_selection')->getSelectionHandler($field_definition, $this->getEntity(), $target_type)->getReferenceableEntities();
    }

so the answer is we are getting reference-able entities form ER selection plugins in core which are completely secure.

What happens if there are 1000s of nodes and someone (stupidly) uses this? Should we check that in the is available method too? To make sure that people don't bust their site.

Isn't ER has the same problem? We can create evil like views_field_view.

jibran’s picture

Issue summary: View changes
Issue tags: +Needs tests
StatusFileSize
new1.97 KB
new8.57 KB
new8.63 KB
new2.5 KB
+++ b/src/Plugin/Field/FieldWidget/DynamicEntityReferenceOptionsTrait.php
@@ -29,16 +29,6 @@ trait DynamicEntityReferenceOptionsTrait {
-  protected function supportsGroups() {

Now select list supports option groups.

jibran’s picture

StatusFileSize
new7.06 KB
new15.35 KB

Added tests for defaultValues.

jibran’s picture

Issue tags: -Needs tests
StatusFileSize
new8.34 KB
new22.09 KB

And we have a core bug.

Status: Needs review » Needs work

The last submitted patch, 6: 2413641-6.patch, failed testing.

jibran’s picture

StatusFileSize
new2.89 KB
new23.53 KB

Created #2426781: Custom OptionWidget have no empty option label for fails in #6. Meanwhile the work around.

jibran’s picture

Status: Needs work » Needs review
larowlan’s picture

Status: Needs review » Reviewed & tested by the community

jibran+=1000
love the new test coverage

jibran’s picture

Thanks for the review and kind words.

  • jibran committed 956a444 on 8.x-1.x
    Issue #2413641 by jibran: Add OptionWidgets for single value target type...
jibran’s picture

Status: Reviewed & tested by the community » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.