Autocomplete hide id options for use with unique labels

This is the standard behavior of entity reference. You need the ID number for it to function properly.

This may work as designed, but for normal users (visitors) this is confusing... Is it just not possible to code for the NID to be hidden or do you just not want to support this feature?

This module works perfectly the way I am looking to use it, but the NID showing is an issue for me...

Please let us know if you can at least consider this as a feature request or if we should look elsewhere for a solution.

Thank you.
PK

Feature request it is. I am not the maintainer of the module but I do have a project at my day job that needs this as well.

Here is how I have been thinking about tackling this:
1) append a hidden field to the end of the autocomplete widget field with a name like field_name_und_0_target_id_id or something like that.
2) update the autocomplete widget to strip out the parenthesis and insert the target id into the hidden field using jQuery.
3) get Entity Reference to look for the hidden field first and use that id as the value instead of the text field or if that value is blank let the normal process continue.

I think there is work going on at #1389238: Autocomplete widget improvements to help with some of the validation issues.

It should be noted that this issue is not intended to fix the validation issues or to automatically attempt to add entities if they do not exist. It is just a UI improvement for view the reference ids.

I appreciate it!

Even if just a temporary fix, this would be very welcomed! :-)

Let us know if you need any help testing.
-PK-

I'm looking for this as well

Entityreference is not in the business of providing new UI elements. There are alternative autocomplete implementations that you can probably leverage.

I see kind of a unique autocomplete situation with entity reference though. Feel free to close again if you disagree or if you know of an existing UI module that can handle this. The catch to entity reference is that we need a way of storing the entity id whereas a typical autocomplete does not rely on that. Several clients have complained about confusion with having the node id showing in the autocomplete field. They don't really care about the number but do care about the title. I think this whole process could be taken care of with javascript that converts the text field to a hidden field and adds a new autocomplete field that updates the hidden field automatically. The hidden field keeps the name of the original element and the value includes the node id in parenthesis so that gets validated the same. The new text field will strip out the parenthesis and node id for display. Maybe it has some sort of visual indicator as well when it has an exact match is being used with a node id.

I have also had complaints from users being confused by the ids in parenthesis.
And the fact that in the autocomplete suggestion there is no distinction between entities with the same label.

My feeling is that this is best approached by treating the autocomplete like what it is: a textfield.
A textfield that offers suggestions on what to type when you have javascript enabled, but still a free-form textfield in which the user can enter anything they like.

What is needed for the entityreference usecase is an input element that allows a user to select a distinct option from a (potentially large) list of predefined options with potentially duplicate labels.

In the mean time there is attached patch.
It changes the display of the ids from (xx) to [id:xx] which seems to be far less confusing, especially for windows users.
It also displays the ID in the autocomplete suggestions so users are able to distinguish different entities with the same label. This also removes the dissonance caused by the box filling with something different from what the user clicked.
And finally it adds an option to the widget settings to remove the ids altogether. This should only be enabled when your entities have unique labels.

case sensitivity fail in patch :(

This is how the core autocomplete widget works everywhere. We are not doing anything special here. I'm open to the idea to have integration with a better autocomplete widget in Entity Reference, but let's not hack around with the core autocomplete.

Sorry Damien, but I disagree.

The core autocomplete widget used everywhere equates the input with the value, which is something Entity Reference changes; it uses a value (entity id) different from the input (entity label).

This issue and patch is specifically about improving the usabilitly of this important difference that Entity Reference introduces.

Perhaps we should move the widgets from the Entity Reference module to a separate module?
Your thoughts?

Please review alternative autocomplete libraries. As I said, I'm open to integrate with an alternative autocomplete implementation, but as far as core is going, this is what you get, and I'm not going to approve mucking with it.

I'm not sure we understand each other.

You are saying that I should fork the autocomplete functionality of Entity Reference into my own module if I want to see usability improvements on it?

Entityreference is not in the business of providing new UI elements. There are alternative autocomplete implementations that you can probably leverage.

1. Entityreference provides two autocomplete widgets.
2. The only other autocomplete functionality I can find that has value != input is in the References modules and that is poor compared to the Entity Reference implementation. I am not aware of any others.

The funny thing is that my patch actually brings the Entity Reference autocomplete closer to the drupal core autocomplete, so your comment confuses me.

I think hes talking about integrating into a project like this: http://drupal.org/project/autocomplete_deluxe

I'm including a lot more content in the autocomplete like full address information, but when you click on it, it puts everything into the input box. I'm trying to find a way to just include just the title... I don't care if the number is entered, I just don't want the address entered.

#11: entityreference-autocomplete-1411304-9.patch queued for re-testing.

I'd just like to say that this is an issue for clients I'm currently working with.
I'm looking at using the method described here:
http://stackoverflow.com/questions/1515722/removing-nidn-in-nodereferenc...

http://drupal.org/project/chosen_ajax

Just out of curiosity why a new project instead of implementing changes with http://drupal.org/project/chosen?

not the same thing

There is a duplicate: http://drupal.org/node/1802916

update

I'm running version 1.1 right now, and the patch in #11 can only be partially applied. I've also applied patches from the duplicate at http://drupal.org/node/1802916, but that didn't seem to work.

I just thought I would update this issue with a sandboxed module that I discovered https://drupal.org/sandbox/peem/1569354. This project looks promising and is exactly what I require and what is asked for in this issue. There maybe possibly an easier way to go about it. Seems to work well. Though I do have issues if I add field validation.

11: entityreference-autocomplete-1411304-9.patch queued for re-testing.

Rolled #11 against 7.x-1.1, but this time keeping it as ($id) instead of [id:$id] when id's are not hidden.

Lets see if this does anything.

#26 was looking correct in the autocomplete, but wasn't saving on submit, this time including the fix from #2185141-1: Required entity reference is possible to save with invalid, but tricky content. to allow saving.

New plan to address the non-saving issue, postponed on #1959624: Autocomplete widgets not referencing the single entity result and #1702172: Saving allowed even when input is not valid in autocomplete results, then this patch should apply, also rolled against dev this time.

Like previously mentioned, Chosen Ajax works pretty good to solve this. Also Multiple Selects plus Chosen is a nice solution... and if you have trouble mixing with Entity Connect see https://www.drupal.org/node/2108549

Patch #29 works well for me in 7.x-1.1

I'm somewhat hesitant to post this patch as I see it as a hack, not a proper fix.

What it does is str_pad the label with white spaces up to a length of 110, then adds the (entity_id) at the end. The result is that the content of the autocomplete field is longer than the input field itself and the id is beyond the edge. Hacky, I know. This also leads to a problem when you want to edit the field. I will probably use this patch as is until this is fixed elsewhere. I will also implement a js select fix to autoselect the full contents when editing.

It works for me, but there might be other consequences elsewhere that I don't know about. Caveat emptor!

If you consider this patch to be too bad, I'd be happy to remove it. I'm not proud of this, it's just a quick fix.

We are using the patch #29 but get an issue when reference entities has '"', or ',' on its title.
It throws this error : There are no entities matching "node, title"
Made this patch based on #29 also fixing this problem.

Patch #29 worked for me on node add but if I edit the node, I can see the ID #.

I modified the regex that looks up entity ids since it was not matching anything with close quotes. Hopefully this new approach does the trick. I don't speak fluent Regex...

Updated patch from #38 to apply to version 1.4 (interdiff might be tricky as code just moved around)

There is another work-around to the UI flaw of having the internal ids appearing in autocomplete selections. In my case I wrote a jquery function triggered by 'autocompleteSelect' on this field. When the user successfully selects an item, it executes a small menu callback which outputs the selected result in html, via .get() in the js that grabs the nid out of the selected text in the field and passes that to this menu callback. The output of this is put within a div next to the field (placed there via a reference_field_alter hook which adds a #suffix of the empty div), and the autocomplete field is hidden. Also a link is written into the displayed result that allows the user to try again -- with a click event that hides the display and once again shows the autocomplete field. This is a satisfying experience for the user, as it confirms that their selection was found in the system, and the menu callback allows a more complete and "pretty" display of the selection to confirm it. Also in my case, the autocomplete field results are supplied by a custom callback by changing the #autocomplete_path, which gives us more control over the results shown (which we needed based on our particular requirements here). The values in the results array do not need the nid in them, so in the available selections, the user does not see the nids; and once selected, the result with the nid in it (supplied by the index of the autocomplete result) doesn't get shown because of the replacement routine defined above.

This sounds like a lot of work, but believe it or not, it can be done without much code.

The regex in #31 might have been a little bit outdated, but the regex in #38 is completely broken, on further investigation it turns out we don't need the regex changes at all as we're sticking with (#) rather than switching to [id:#], which for me would be an undesirable change and at the very least out of scope.

I looked at the quote and comma stuff and updated autocomplete tags to use drupal_implode_tags(), and changed MauHG's code to use the method from drupal_explode_tags() instead. This works for all four combination (autocomplete+id, autocompletetags+id, autocomplete+hideid, autocompletetags+hideid).

updated patch #39 for entityreference 1.5

@wranvaud Would appreciate if you could checkout my thoughts/patch in #41, I think it accounts for everything raised in a nicer way.

I have updated patch 41 to work with 7.x-1.x as of today.

Have tested it and it seems to work well.

Still postponed on #1702172: Saving allowed even when input is not valid in autocomplete results.

However I wanted to use views mode with hide id, so here are the tweaks I made to #45 to allow this, if someone would like to roll a patch please do.

views/entityreference_plugin_display.inc:75

        ...
        // Build the condition using the selected search fields
+       $fields = array();
        foreach ($style_options['search_fields'] as $field_alias) {
          if (!empty($field_alias)) {

            // Get the table and field names for the checked field.
            if (empty($this->view->field[$field_alias]->field_info)) {
              $field = $this->view->query->fields[$this->view->field[$field_alias]->field_alias];
            }
            else {
              $field_table = $this->view->query->ensure_table($this->view->field[$field_alias]->table, $this->view->field[$field_alias]->relationship);
              $this->view->query->add_field($field_table, $this->view->field[$field_alias]->real_field, $this->view->field[$field_alias]->field, array());
              $field = $this->view->query->fields[$this->view->field[$field_alias]->field];
            }
            // Add an OR condition for the field
            $conditions->condition($field['table'] . '.' . $field['field'], $value, 'LIKE');
+           $fields[] = $field['table'] . '.' . $field['field'];
          }
        }

+       $conditions->where("CONCAT(" . implode(", ' - ', ", $fields) . ") LIKE :value ESCAPE '\\\\'", array(':value' => $value));
        $this->view->query->add_where(NULL, $conditions);
        ...

Rerolled the patch as per the latest release.

Rerolled the patch.

Patch update

I create custom module name entityreference_autocomplete_hide_ids.
This module force all entityreference widget autocomplete to hide entitiy id.
My custom module works well.
Check it out here:
https://www.drupal.org/sandbox/m_roji28/3025626

Updated the patch.

Reroll of patch #54 for the updated 1.x-dev branch

Thanks for the reroll @jplana, here's a review of the contents of the patch. I'll try to post an updated patch with these items addressed and test it out further.

1. +++ b/entityreference.module
   @@ -1097,7 +1105,7 @@ function entityreference_autocomplete_callback_get_matches($type, $field, $insta
   -      $prefix = count($tags_typed) ? implode(', ', $tags_typed) . ', ' : '';
   +      $prefix = count($tags_typed) ? drupal_implode_tags($tags_typed) . ', ' : '';
   

   This looks great, but a bug fix that could probably be committed on its own?

2. +++ b/entityreference.module
   @@ -1116,14 +1124,14 @@ function entityreference_autocomplete_callback_get_matches($type, $field, $insta
   -        $matches[$prefix . $key] = '<div class="reference-autocomplete">' . $label . '</div>';
   +        $matches[$prefix . $key] = '<div class="reference-autocomplete">' . $key . '</div>';
   

   This looks unrelated and/or a mistake, it should still present the label.

3. +++ ./entityreference.module	2020-08-06 08:45:52.000000000 -0700
   @@ -800,6 +802,12 @@
   +      '#title' => t('Hide ids'),
   +      '#description' => t('If your target entities have unique labels you may choose not to have the ids shown to the user. Note that this setting will make it impossible to reference entities with non-unique labels!'),
   

   nit: This should be 'IDs' instead of 'ids'

4. +++ ./plugins/selection/EntityReference_SelectionHandler_Generic.class.php	2020-08-06 08:46:47.000000000 -0700
   @@ -159,6 +159,9 @@
   +    $match = trim(str_replace('""', '"', preg_replace('/^"(.*)"$/', '\1', $match)));
   

   What is this about? Probably needs more explanation or removal?

5. +++ ./views/entityreference_plugin_display.inc	2020-08-06 08:47:53.000000000 -0700
   @@ -87,9 +88,11 @@
   +      $conditions->where("CONCAT(" . implode(", ' - ', ", $fields) . ") LIKE :value ESCAPE '\\\\'", array(':value' => $value));
   

   Maybe why postgres is failing, is this needed still?

I created a follow up for #1411304-58: Autocomplete hide id options for use with unique labels #1 at #3163902: Use drupal_implode_tags() instead of just implode() for autocomplete matches

Dealt with items 1, 2, 3, and 5 from the comment above (see interdiff). @MustangGB Let me know what it's about and if it's needed for something.

This totally still needs #1702172-80: Saving allowed even when input is not valid in autocomplete results to function with Views.

MustangGB mentioned this as one of three recurring issues (that always come up, needing patching)

#2979886-6: Release 7.x-1.7-rc1 with all of these enumerated changes

the other two are:

#1896210: 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)

AND

#1702172: Saving allowed even when input is not valid in autocomplete results

straight up reroll of 60 just to make cicd super happy no fuzz

this time should work

Only giving credit to two people?

I'll amend

Aww, thank-you, glad to see this module getting some love.

https://www.drupal.org/project/entityreference/releases/7.x-1.6-rc2

https://www.drupal.org/project/entityreference/releases/7.x-1.7

please try the latest release

https://www.drupal.org/project/entityreference/releases/7.x-1.9