Im using the module Entity reference 7.x-1.0-beta3 in a clean drupal 7.1 core.
And I have created an Entity Reference field in a content_type B with a autocomplete widget to list all the node's name of a content_type A.
The problem is the display is worked, but while I select a value from the autocomplete result list, it not only returns the node's name, but with an additional "(nid)" ex: "nodename1 (5)".
I'd appreciate if some one could help me.
Thank you!

#39 interdiff-1411304-38-39.txt8.37 KBwranvaud
#39 entityreference-autocomplete_comma-1411304-39.patch5.59 KBwranvaud
#38 interdiff-1411304-36-38.txt2.13 KBezeedub
#38 entityreference-autocomplete_comma-1411304-38.patch6.14 KBezeedub
#36 entityreference-autocomplete_comma-1411304-36.patch5.64 KBMauHG
#29 entityreference-autocomplete-1411304-29.patch4.94 KBMustangGB
FAILED: [[SimpleTest]]: [MySQL] 23 pass(es), 30 fail(s), and 6 exception(s). View
#11 entityreference-autocomplete-1411304-9.patch5.56 KBJvE
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch entityreference-autocomplete-1411304-9_0.patch. Unable to apply patch. See the log in the details link for more information. View


haydeniv’s picture

Status: Active » Closed (works as designed)

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

sunyu0072007’s picture

Ok, got it, I hope there could be a way to disable the way view in future. thank you for you answer :)

pumpkinkid’s picture

Category: bug » feature
Priority: Major » Normal
Status: Closed (works as designed) » Active

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.

haydeniv’s picture

Title: Entity reference, it not only returns the node's name, but with an additional "(nid)" ex: "nodename1 (5)". » Autocomplete widget should store reference id in hidden field instead of in autocomplete text field
Assigned: sunyu0072007 » Unassigned

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.

pumpkinkid’s picture

I appreciate it!

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

Let us know if you need any help testing.

Desi Raaj’s picture

I'm looking for this as well

Damien Tournoud’s picture

Status: Active » Closed (won't fix)

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

haydeniv’s picture

Status: Closed (won't fix) » Active

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.

JvE’s picture

Component: Code » User interface
Status: Active » Needs review
5.56 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch entityreference-autocomplete-1411304-9.patch. Unable to apply patch. See the log in the details link for more information. View

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.

Status: Needs review » Needs work

The last submitted patch, entityreference-autocomplete-1411304-9.patch, failed testing.

JvE’s picture

Status: Needs work » Needs review
5.56 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch entityreference-autocomplete-1411304-9_0.patch. Unable to apply patch. See the log in the details link for more information. View

case sensitivity fail in patch :(

Damien Tournoud’s picture

Status: Needs review » Closed (won't fix)

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.

JvE’s picture

Title: Autocomplete widget should store reference id in hidden field instead of in autocomplete text field » Autocomplete widget entity id improvements
Status: Closed (won't fix) » Needs review

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?

Damien Tournoud’s picture

Title: Autocomplete widget entity id improvements » Autocomplete widget improvements
Status: Needs review » Active

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.

JvE’s picture

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.

iLLin’s picture

I think hes talking about integrating into a project like this:

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.

pribeh’s picture

Status: Active » Needs review
lionfish-dupe’s picture

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:

Cristhian’s picture

haydeniv’s picture

Just out of curiosity why a new project instead of implementing changes with

Cristhian’s picture

not the same thing

weri’s picture

There is a duplicate:

weri’s picture

Issue summary: View changes


Yelldon’s picture

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, but that didn't seem to work.

I just thought I would update this issue with a sandboxed module that I discovered 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.

MustangGB’s picture

Status: Needs review » Needs work

The last submitted patch, 11: entityreference-autocomplete-1411304-9.patch, failed testing.

MustangGB’s picture

Version: 7.x-1.x-dev » 7.x-1.1
Issue summary: View changes
4.11 KB
FAILED: [[SimpleTest]]: [MySQL] 23 pass(es), 30 fail(s), and 6 exception(s). View

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

MustangGB’s picture

Status: Needs work » Needs review

Lets see if this does anything.

Status: Needs review » Needs work

The last submitted patch, 26: entityreference-autocomplete-1411304-25.patch, failed testing.

MustangGB’s picture

Status: Needs work » Needs review
4.94 KB
FAILED: [[SimpleTest]]: [MySQL] 23 pass(es), 30 fail(s), and 6 exception(s). View

#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.

Status: Needs review » Needs work

The last submitted patch, 29: entityreference-autocomplete-1411304-29.patch, failed testing.

MustangGB’s picture

Version: 7.x-1.1 » 7.x-1.x-dev
Status: Needs work » Postponed
4.11 KB

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.

MustangGB’s picture

socialform’s picture

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

edutrul’s picture

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

odegard’s picture

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.

MauHG’s picture

5.64 KB

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.

ashopin’s picture

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

ezeedub’s picture

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...

wranvaud’s picture

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

bob.hinrichs’s picture

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.