Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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!
Comment | File | Size | Author |
---|
Comments
Comment #1
haydeniv CreditAttribution: haydeniv commentedThis is the standard behavior of entity reference. You need the ID number for it to function properly.
Comment #2
sunyu0072007 CreditAttribution: sunyu0072007 commentedOk, got it, I hope there could be a way to disable the way view in future. thank you for you answer :)
Comment #3
pumpkinkid CreditAttribution: pumpkinkid commentedThis 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
Comment #4
haydeniv CreditAttribution: haydeniv commentedFeature 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.
Comment #5
pumpkinkid CreditAttribution: pumpkinkid commentedI appreciate it!
Even if just a temporary fix, this would be very welcomed! :-)
Let us know if you need any help testing.
-PK-
Comment #6
Desi Raaj CreditAttribution: Desi Raaj commentedI'm looking for this as well
Comment #7
Damien Tournoud CreditAttribution: Damien Tournoud commentedEntityreference is not in the business of providing new UI elements. There are alternative autocomplete implementations that you can probably leverage.
Comment #8
haydeniv CreditAttribution: haydeniv commentedI 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.
Comment #9
JvE CreditAttribution: JvE commentedI 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.
Comment #11
JvE CreditAttribution: JvE commentedcase sensitivity fail in patch :(
Comment #12
Damien Tournoud CreditAttribution: Damien Tournoud commentedThis 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.
Comment #13
JvE CreditAttribution: JvE commentedSorry 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?
Comment #14
Damien Tournoud CreditAttribution: Damien Tournoud commentedPlease 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.
Comment #15
JvE CreditAttribution: JvE commentedI'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?
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.
Comment #16
iLLin CreditAttribution: iLLin commentedI 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.
Comment #17
pribeh CreditAttribution: pribeh commented#11: entityreference-autocomplete-1411304-9.patch queued for re-testing.
Comment #18
lionfish-dupe CreditAttribution: lionfish-dupe commentedI'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...
Comment #19
Cristhian CreditAttribution: Cristhian commentedhttp://drupal.org/project/chosen_ajax
Comment #20
haydeniv CreditAttribution: haydeniv commentedJust out of curiosity why a new project instead of implementing changes with http://drupal.org/project/chosen?
Comment #21
Cristhian CreditAttribution: Cristhian commentednot the same thing
Comment #22
weri CreditAttribution: weri commentedThere is a duplicate: http://drupal.org/node/1802916
Comment #22.0
weri CreditAttribution: weri commentedupdate
Comment #23
Yelldon CreditAttribution: Yelldon commentedI'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.
Comment #24
MustangGB CreditAttribution: MustangGB commented11: entityreference-autocomplete-1411304-9.patch queued for re-testing.
Comment #26
MustangGB CreditAttribution: MustangGB commentedRolled #11 against 7.x-1.1, but this time keeping it as ($id) instead of [id:$id] when id's are not hidden.
Comment #27
MustangGB CreditAttribution: MustangGB commentedLets see if this does anything.
Comment #29
MustangGB CreditAttribution: MustangGB commented#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.
Comment #31
MustangGB CreditAttribution: MustangGB commentedNew 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.
Comment #32
MustangGB CreditAttribution: MustangGB commentedComment #33
socialform CreditAttribution: socialform commentedLike 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
Comment #34
edutrul CreditAttribution: edutrul commentedPatch #29 works well for me in 7.x-1.1
Comment #35
odegard CreditAttribution: odegard commentedI'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.
Comment #36
MauHG CreditAttribution: MauHG commentedWe 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.
Comment #37
ashopin CreditAttribution: ashopin as a volunteer commentedPatch #29 worked for me on node add but if I edit the node, I can see the ID #.
Comment #38
ezeedub CreditAttribution: ezeedub commentedI 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...
Comment #39
wranvaud CreditAttribution: wranvaud at Phase2 commentedUpdated patch from #38 to apply to version 1.4 (interdiff might be tricky as code just moved around)
Comment #40
bob.hinrichs CreditAttribution: bob.hinrichs commentedThere 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.
Comment #41
MustangGB CreditAttribution: MustangGB commentedThe 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 fromdrupal_explode_tags()
instead. This works for all four combination (autocomplete+id, autocompletetags+id, autocomplete+hideid, autocompletetags+hideid).Comment #42
MustangGB CreditAttribution: MustangGB commentedComment #43
wranvaud CreditAttribution: wranvaud at Phase2 commentedupdated patch #39 for entityreference 1.5
Comment #44
MustangGB CreditAttribution: MustangGB commented@wranvaud Would appreciate if you could checkout my thoughts/patch in #41, I think it accounts for everything raised in a nicer way.
Comment #45
frjo CreditAttribution: frjo commentedI have updated patch 41 to work with 7.x-1.x as of today.
Have tested it and it seems to work well.
Comment #46
MustangGB CreditAttribution: MustangGB commentedStill 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
Comment #47
Nitesh Sethia CreditAttribution: Nitesh Sethia as a volunteer and at Syngenta commentedRerolled the patch as per the latest release.
Comment #49
Nitesh Sethia CreditAttribution: Nitesh Sethia as a volunteer and at Syngenta commentedRerolled the patch.
Comment #51
Nitesh Sethia CreditAttribution: Nitesh Sethia as a volunteer and at Syngenta commentedPatch update
Comment #53
ijortengab CreditAttribution: ijortengab as a volunteer commentedI 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
Comment #54
Nitesh Sethia CreditAttribution: Nitesh Sethia as a volunteer and at Syngenta commentedUpdated the patch.
Comment #56
jplana CreditAttribution: jplana at The University of British Columbia commentedReroll of patch #54 for the updated 1.x-dev branch
Comment #57
jplana CreditAttribution: jplana at The University of British Columbia commentedComment #58
joelpittetThanks 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.
This looks great, but a bug fix that could probably be committed on its own?
This looks unrelated and/or a mistake, it should still present the label.
nit: This should be 'IDs' instead of 'ids'
What is this about? Probably needs more explanation or removal?
Maybe why postgres is failing, is this needed still?
Comment #59
joelpittetI 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.
Comment #60
joseph.olstadMustangGB 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
Comment #61
joseph.olstadstraight up reroll of 60 just to make cicd super happy no fuzz
Comment #63
joseph.olstadComment #64
joseph.olstadComment #66
joseph.olstadthis time should work
Comment #67
joseph.olstadComment #69
joseph.olstadComment #70
joseph.olstadComment #72
MustangGB CreditAttribution: MustangGB commentedOnly giving credit to two people?
Comment #73
joseph.olstadI'll amend
Comment #76
joseph.olstadComment #77
MustangGB CreditAttribution: MustangGB commentedAww, thank-you, glad to see this module getting some love.
Comment #78
joseph.olstadhttps://www.drupal.org/project/entityreference/releases/7.x-1.6-rc2
Comment #80
joseph.olstadhttps://www.drupal.org/project/entityreference/releases/7.x-1.7
Comment #81
joseph.olstadplease try the latest release
https://www.drupal.org/project/entityreference/releases/7.x-1.9