When filtering autocomplete by a view #default_value always be the entity title instead of the custom view result (e.g. a field on the entity)

The default value of the autocomplete fields is being set to just the label of the entity (ignoring the views settings).

This patch adds functionality to the views plugin to get the output from the view not just the entity label.

I tested this out and it solves the problem of this issue.

I made a couple of minor tweaks to check if the entity_id is empty before initializing the view and using the php end of line character.

Patch in #2 works for me.

News? Should this be committed?

Same problem here

Patch in #2 doesn't apply cleanly anymore. Re-created a new one with the same code, patch attached.

Marking as RTBC once this solves the problem for me also

Patch #5 works for me

RTBC from me as well.

Confirming Patch #5 works for me as well.

Incidentally, is there an option to further remove the [user:uid] which shows up in parentheses in the autocomplete field on the edit page after searching and selecting the referenced field?

For example, if I have a profile2 called "Main Profile" and reference a street address field for a user (who has the user ID 23) this patch correctly changes the display of the reference entity from "Main Profile (23)" on the edit page, to "123 Fake Street (23)" - however, I think hiding the user ID would be handy as well as possible a further option (or possibly as the default)?

Just to confirm for anyone else searching for this, the patch edits the display on the /node/[node:nid]/edit page, not the view page (/name-of-content). The view display can be handled by an entity reference view and modifying the "Manage Display" page of the content type (/admin/structure/types/manage/[name-of-content-type]/display

Ya its working fine.
Similarly i want to set default autocomplete value. The value shouln't displayed with nid. How to set default autocomplete value without nid?

Important issue. I can confirm that this problem still exists and the patch fixes it.
Is there an active maintainer willing to pull this into the next release to have a consistent behaviour?

Setting the priority up because the UI is inconsistent currently and it's not possible to fix this without patching / coding.

As it seems this patch eventually breaks entity label output from an entity reference field in a view. I'll check that and write how to reproduce. Leaving state until it's clear that the patch is the reason.

My guess in #12 was right. There is a logical bug in the patch which leads to wrong label display.

This part is wrong:

/**
 * Implements hook_field_formatter_view().
 */
function entityreference_field_formatter_view($entity_type, $entity, $field, $instance, $langcode, $items, $display) {
  $result = array();
  $settings = $display['settings'];

  // Rebuild the items list to contain only those with access.
  foreach ($items as $key => $item) {
    if (empty($item['access'])) {
      unset($items[$key]);
    }
  }

  switch ($display['type']) {
    case 'entityreference_label':
      $handler = entityreference_get_selection_handler($field, $instance, $entity_type, $entity);

      foreach ($items as $delta => $item) {
        $label = $handler->getLabel($item['entity'], $item['target_id']);

In this function it doesn't seem right to me to use the views output of the label.
The given function handles the output of the entityreference field in a view. What we'd like to output there is NOT the result of the entityreference_view but the label of the referenced entity!

So this line should still return the old value which is simply possible by usig NULL as second argument:

$label = $handler->getLabel($item['entity'], NULL);

I've tested this and the behaviour is correct afterwards. I'll upload a corrected patch.
This is still an important bugfix from my point of view to correct the inconsistent, wrong behaviour.

Patch with fixed field_formatter_view attached. Please review for RTBC! :)
That should hopefully be final.

+1 for RTBC!

+1 for RTBC!

#14 ready to be commited as soon as possible.
Is there an active module maintainer?

Please add some test cases so that we can test this further going forward with creating a new release.

I can't reproduce this problem anymore with the latest 7.x-1.x (http://cgit.drupalcode.org/entityreference/commit/?id=4801560). I was using the patch in #5, but upgraded to the latest dev version to test #2010898: Use tokens for entity selection view arguments, and that patch (nor the one in #14) doesn't apply anymore. But it seems we might not need it anymore.

Can anyone else test to see if this problem got resolved?

Hello,

Just a question about the escaping of the default value.

I don't understand why you escape string with a comma because in my case, the string is already escaped (I do nothing for that).
So instead to have "Hello, world!", I have ""Hello, world!""...

I just use an autocomplete whit an entity reference view...

Tried both patched latest committed ver (sep 2016) and dev ver (dec 2016) and still experiencing the problem of selection value changing on the displayed node. I have attempted different Display Formats including Label, Entity ID, Services Raw without getting the value I originally selected at node creation. Rendered Entity format throws an error on display (likely unrelated issue).
Screen capture tells the story.

selecting name from a view list

resulting node gives label of entity

I'm in the process of upgrading to 1.4 and still need this patch. Here's a very simple reroll, only line number changes.

Looks like the entityreference_field_formatter_view() accommodation is no longer needed, so here is an updated version that doesn't bother messing around with function definitions.

On further investigation #2247937: add option to label formatter to show labels without considering user access was not good for fields using views, so we do need to handle that.

I don't agree with the `entityreference_field_formatter_view` approach, specifically checking the handler type. I am thinking a better way to handle this situation would be to add an optional `bypass_access` parameter to `getLabel` which could prevent the duplicate access check. Although this API breaking so...

Either way, the `entityreference_field_formatter_view` change isn't related to the issue so I suggest reverting back to `entityreference-1896210-24.patch` and opening another issue for the `entityreference_field_formatter_view` situation.

@MustangGB, which patch are you using here?

Still using #26 (entityreference-1896210-25.patch) on multiple sites.

Not saying it's the best or correct way to fix this, but I haven't had to revisit it for the past 3 years.