Entity reference field View output is not used for selected entity display

I'm might be up for making a start with this, but I need some guidance.

You say this is a regression from D7, could you point to the code in D7 that enables this? I scratched around in the entity_reference module and saw nothing obvious, but my understanding of D7 is very thin.

For D8, my first guess would be to modify the entity reference widget. Basically modify the formElement method so that each time it is called it checks the delta to see if it's the last (i.e. new value field item). If it is the last, then the code should work as it currently does. If it is not the last (i.e. an existing value) then it should check to see if we're using the views handler, and if we are then instead of the current code to build a form element, it should render a single row view instead. I'm very vague around what this last point means and how to do it.

However, that seems very invasive to the entity reference widget, which rather defeats the point of having selection handlers as plugins. Maybe it would be better to add an additional "renderableSelectionHandlerInterface" to the selection handlers. The widget would then see if the handler pluginimplemented that interface, and if it did call a "buildItem" method on it the handler plugin; if it did not (or if that returned null) it would fall back to building its current form element.

core/lib/Drupal/Core/Entity/Element/EntityAutocomplete.php looks like a good start. valueCallback() calls getEntityLabels(), when it could check for views under "#selection_settings" and process that accordingly.

For some example views code, see the interdiff in post 70.

Here's a start. It takes into account multiple results for a single field separated by commas.

I'm not sure if this is the right approach so there aren't any tests.

A selection handler would be more flexible.

A selection handler would be more flexible.

+++ b/core/lib/Drupal/Core/Entity/Element/EntityAutocomplete.php
@@ -68,9 +69,14 @@ public static function valueCallback(&$element, $input, FormStateInterface $form
-        // Extract the labels from the passed-in entity objects, taking access
-        // checks into account.
-        return static::getEntityLabels($element['#default_value']);
+        if ($element['#selection_handler'] == 'views') {
+          return static::getEntityViewsResults($element);
+        }
+        else {
+          // Extract the labels from the passed-in entity objects, taking access
+          // checks into account.
+          return static::getEntityLabels($element['#default_value']);
+        }

Yes, ideally EntityAutocomplete::getEntityLabels() would invoke a method on the selection handler, because only it knows how to properly format its output.

Yes, ideally getEntityLabels() would invoke a selection handler because only it knows how to properly format its output.

In which case should we create a method with a more generic name like getEntityDisplay, and deprecate getEntityLabels?

On a separate subject, perhaps code here should build on the reorganisation in #2787873: Add a base class for entity reference selection handlers and fix the structure of their configuration which is quite well advanced.

I wouldn't deprecate getEntityLabels() but add an additional optional argument to it, for example SelectionInterface $selection_handler = NULL, which, if given, will get the output from the passed-in selection through a getAutocompleteText() method.. or something like that.

We're still using the patch in #4 with Drupal 8.2.x which is working well. When #2787873: Add a base class for entity reference selection handlers and fix the structure of their configuration is in we may revisit this if we're planning to update the relevant site to 8.4.

I am encountering two issues about using entity reference view display in Drupal 8.6.1:

1) At the /node/[nid]/edit page, the select list widget for entity reference view display is showing only the username of the current logged in user for all the available options... and this is almost fixed with this patch (https://www.drupal.org/project/drupal/issues/2174633) and it is working for me !!

2) At the /node/[nid] page, the output of the select list entity reference view is broken and displaying only the username of the logged in user and referencing the user page as well !
I have been redirected to this issue as it will sove my problem, but after i applied the patch #4, the problem still exist and nothing has really changed !

And also I see that the last update on this issue was 2 years ago so am i on the right track or I am missing something here !?

At the /node/[nid] page, the output of the select list entity reference view is broken and displaying only the username of the logged in user and referencing the user page as well !

I don't think this issue will solve your problem. I think this issue is about what is shown in a widget or other form element e.g. at node /[nid]/edit for already selected items.

#2174633: View output is not used for entityreference options covers what is show in the selector when selecting new items, this covers the display ON THE FORM of already selected items.

In general to control what appears at node/[nid] you want to use the 'Manage display' not the 'Manage form display UI', and in particular you would normally use a 'Rendered entity' formatter not the 'Label' formatter.

However, if it's node author you want to mess with you're out of luck, because that's got weird legacy issues. You may well find it easiest just to hack what you want into your node theme template, it all depends on your exact use case and I suggest you try Drupal Answers if you want help with it.

In general to control what appears at node/[nid] you want to use the 'Manage display' not the 'Manage form display UI', and in particular you would normally use a 'Rendered entity' formatter not the 'Label' formatter.

I am aware already about the use of the "manage display" and not the "form display" but your mentioning about the "render entity" formatter put me again on the right track and now all is working as expected !

Or at least until this issue will be officially fixed !

Thank you once again, god bless,

I added new treatments.

When the autocomplete field is not a style tag, you do not need to enclose the value with double quotation marks.

When we have characters like & in the title, it is transformed into & amp;
To solve I added the html_entity_decode function before the strip_tags

I use the 2796341-18.patch and it works for me. It would be good to get this committed.

I applied this patch and it is working as expected.

Just out of curiosity, is there a reason why the Entity ID is appended to the value?

For example, we have this currently:

$label = html_entity_decode(strip_tags(\Drupal::service('renderer')->renderPlain($result)))  . ' (' . $entity_id . ')';

Why not this instead:

$label = html_entity_decode(strip_tags(\Drupal::service('renderer')->renderPlain($result)));

I don't see a way to override this from within views. Perhaps I'm missing something, or just don't understand the history here.

Anyway, thanks for the excellent patch, huge help for me.

#22 the appended id is to disambiguate entities with identical labels

Maybe we can get this moving now that it's related issue is fixed?

Yup, it would be good to make some progress here :) See #7 for my thoughts on what the patch should do.

Patch in comment 18 applies smoothly to 8.8.5 and resolves the issue correctly - this is RTBC.
May I suggest any additional changes go into new issues?

Now that #2174633 is committed this will be a nice issue to resolve as well.

Path for 8.9.x

Clarified what this issue is about in the summary according to #16

I have tested this with 8.9.x and it seems to work.

Thanks, this looks like the patch is long out of date, e.g. functions like drupal_set_message are gone in 9.x, and old array syntax is something we don't use anymore.

In addition we need some test coverage here.

We could also use an issue summary update to use the template, including steps to reproduce etc.

Also, there is no entity reference module anymore, so changing the component

1. +++ b/core/lib/Drupal/Core/Entity/Element/EntityAutocomplete.php
   @@ -341,6 +347,56 @@ public static function getEntityLabels(array $entities) {
   +  public static function getEntityViewsResults($element) {
   

   this needs a docblock

2. +++ b/core/lib/Drupal/Core/Entity/Element/EntityAutocomplete.php
   @@ -341,6 +347,56 @@ public static function getEntityLabels(array $entities) {
   +    $entity_ids = array();
   ...
   +    $results = array();
   ...
   +    $labels = array();
   

   this is using old array syntax

3. +++ b/core/lib/Drupal/Core/Entity/Element/EntityAutocomplete.php
   @@ -341,6 +347,56 @@ public static function getEntityLabels(array $entities) {
   +      drupal_set_message(t('The reference view %view_name cannot be found.', array('%view_name' => $view_name)), 'warning');
   ...
   +      drupal_set_message(t('You do no have access to the reference view %view_name.', array('%view_name' => $view_name)), 'warning');
   

   drupal_set_message has been removed, this needs to use the messenger service

4. +++ b/core/lib/Drupal/Core/Entity/Element/EntityAutocomplete.php
   @@ -341,6 +347,56 @@ public static function getEntityLabels(array $entities) {
   +        'limit' => 0,
   +        'ids' => $entity_ids
   +      ]);
   

   the indenting is wrong here

Created patch for 9.1.x. Covered fixes addressed in #32.

Thanks @snehalgaikwad! Please post an interdiff where possible when working on a patch.

NW for IS update and tests.

Yes @jonathanshaw. I created patch for 9.1.x version(prev patch was for 8.9.x) with fixes mentioned so didn't add interdiff.

NW per #37 as the fix needs to be fundamentally different

Thank you! I can confirm patch #28 works fine with 8.9.6.

Do we need the "($entity_id)" in the output of a ViewsSelection?

I think thats only releated to the EntityAutocomplete element. When you are using another element, for example select2, you don't need and want the braces with the entity_id in your results.

Thank you! 2796341-41.patch installs and works without issue on Drupal core 9.0.7, and is exactly what I was looking for.

Thanks for this! I'm on 8.9.11 and #28 applied cleanly. I realized after the fact that none of this appears to be relevant to the 9.x patch, but for anyone using 8.9.x, I cleaned up the code standards issues mentioned in #32, fixed a typo, and added the ENT_QUOTES argument to html_entity_decode() to prevent entities with straight apostrophes (') from being escaped when printed.

Fixed minor CS issues in #47.

Thanks! Just tested with Drupal 9.2 and works perfectly.

Re-rolled patch #41 against 9.2.x

Fixed custom command failure.

@ #52/#53 looks like a typo "entites" should be "entities".

#48 is working on 9.2. #52/#53 look like a different approach.

Not clear why interface renamed in latest patches, I see no reason for it

It needs proper re-roll and address #42

+++ /dev/null
@@ -1,29 +0,0 @@
-interface SelectionWithAutocompleteLabels {

+++ b/core/lib/Drupal/Core/Entity/EntityReferenceSelection/SelectionWithAutocompleteLabelsInterface.php
@@ -0,0 +1,27 @@
+interface SelectionWithAutocompleteLabelsInterface {

needs CR

Here's re-roll and small fixes (including CS)

@chr.fritsch re #44 - yes, entity IDs are needed (frontend could hide'em) otherwise there's no way to differentiate same-labeled entities, there's #2881892: UX: Hide entity ID in autocomplete widget

interdiff is 41 vs 58

Fix CS from #53

FILE: ...ity/EntityReferenceSelection/SelectionWithAutocompleteLabels.php
----------------------------------------------------------------------
FOUND 0 ERRORS AND 2 WARNINGS AFFECTING 2 LINES
----------------------------------------------------------------------
  5 | WARNING | [x] Unused use statement
 14 | WARNING | [ ] Interface names should always have the suffix
    |         |     "Interface"

Please everyone do not post patches that are not descended from #42 #58 / #60 as this is the only approach that has any chance of being committed, and it gets confusing when two different approaches are being worked on in the same issue.

As far as I can see #42 can be addressed fairly easily in EntityAutocomplete::getEntityLabels().

Two bugs that need to be addressed:

• With both #48 and #60 -- titles that contain commas are not getting enclosed in quotes on load. I've confirmed that without any patch from this issue, core does this automatically when using a views filter, so it's a regression introduced by the patch.
• With #60, apostrophes in titles are getting over-escaped. So, for example, a title like "0001-8675302 - I'm in your demo, making you smile (21)" loads as "0001-8675302 - I'm in your demo, making you smile (21)" with #60 applied but not with #48 applied.

I'm going to take a stab at moving #60 over to an issue fork to address this feedback and the feedback from #42.

Also: see #2951134: Single-value autocomplete widgets don't warn about field cardinality, lose data silently if you want non-tag entity reference fields to validate the cardinality of each delta properly. I will not be adding the fix for that here, but it is a complementary fix.

Ok, I believe I've addressed all the feedback and the two bugs I found. Everything should be in MR 2761. Here is the inter-diff from 60:
https://git.drupalcode.org/project/drupal/-/compare/d4407da8d03dc727d7a5...

Each commit contains a detailed description of the changes I made.

Setting back to me to address test failures.

Hiding older patches.

New inter-diff since #60:
https://git.drupalcode.org/project/drupal/-/compare/d4407da8d03dc727d7a5...

I have posted a few suggestions in the MR, please consider if they are relevant

Just to bring this up again as it has been asked a few times in this thread: "why is the (id) appended to the field result value?"

the only reply i see here is in #23: "the appended id is to disambiguate entities with identical labels" - but that's not a good answer. That's a Drupalism and is only a site specific requirement. We have entityref fields accessible to client's. They have no idea what that number means and in many cases, such as for user reference fields, this could even be considered a security issue.

These db id values should not be shown here.

NOTE: i am talking about the result which ends up in the field (not what is shown as options in the autocomplete)

I see all the points and worries but to get forward with this issue and its main focus and primary scope we should prevent to disperse discussion about corners of likes and dislikes in the solution and should minimize the scope as much as possible.

This issue isn't merely important for custom entities and projects like ECK and paragraphs but also for any entity types, which do not have mandatory title (label) field. Also in core, since there are discussions about to change the mandatory title field for nodes too.

EDIT (after further testing): To clarify (also for me) this issues scope here seem to be merely for the use of autocomplete and inline edit reference field formatter and similar form field formatters where you are able to CREATE NEW referenced items. I tested custom entities with select lists and alternative form field widgets like chosen with existing custom entities, and I used Views reference views to build custom Views reference select lists to choose from and the form field preview reflects the selected list item as is. So I assume this should be clarified in the issue summary?

Can somebody who is more into this issue, update the summary and can make some notes about what to do next to get forward so that others can chime in to help? Since this issue is a little bit dated it surely needs updates on the to-do list.

More investigating and maybe "good to know" information: For those who use inline_entity_form for creating new entities in the progress of adding them as references can use ief_table_view_mode to get a custom preview of the reference in the edit form display. This solves the problem of entities which have no "label" (title) field looking like empty entries in the preview. Thanks to @mnico for this contribution and important extension for the IEF workflow.

Taking on additional rework.

I reviewed the MR feedback (thank you, @ameymudras). I've ticketed #3423053: Replace \Drupal calls with proper IoC in form elements under the #2729597: [meta] Replace \Drupal with injected services where appropriate in core meta issue. That issue should be appropriately scoped to rework form elements like the Entity Auto-complete text field to use DI. I am moving both \Drupal::service('plugin.manager.entity_reference_selection') calls in the class into a utility method and adding a todo that references #3423053. I believe that to be the most prudent way to avoid bloating the scope of this issue.

Regarding your feedback, @liquidcms, I agree with what I believe @dqd is saying -- the scope of this issue is to fix what value appears in the autocomplete field when a view is being used to drive selections. The question of whether an ID should be suffixed or not is outside the scope of this issue. The issue you are looking for is #2881892: UX: Hide entity ID in autocomplete widget and until that issue lands, the implementation in this ticket is consistent with both the way that the ID appears during initial selection with a view as well as autocomplete fields that are not driven by a view.

As for your other question, @dqd, it seems like you found a solution to your problem with IEF. Regardless, I have cleaned up the issue description to clarify that this issue is specific to autocomplete text fields. Please let me know if that addresses your issue, since IEF is completely separate.

Linking related issues.

Just updated the branch for 9.5. My next update will update this for 10.1.x.

Updated for 10.1.x.

Updated for 11.x. Ready for re-review.

Issue summary appears to be missing a few sections

Added the missing sections but left TBD on sections for someone more familiar with the issue to speak on.

Also can we hide some of the MRs to just have the intended for 11.x branch. Can be backported later depending when this lands.