Problem/Motivation
During the usability sessions, some participants were confused by the UI of the content reference autocomplete widget. The node ID in parentheses is unclear and in most cases redundant.
Some users removed the ID, thinking that it was a bug or would have a negative effective on the display of the item. Once they removed the ID, the system assumed they were creating a manually entry, and would produce an error on the menu link form.
Huh… I guess you need that.
The node ID is only needed to differentiate between two nodes with the same name. During discussion, we considered this a valid use case.
Proposed resolution
Only show the node ID when there are two results with the same title.
Prefix the value with 'ID:', so it is more clear what the purpose is.
Remaining tasks
Implement the suggestions
Design review
Test
User interface changes
A less confusing node auto complete
API changes
None
Data model changes
None
Comment | File | Size | Author |
---|---|---|---|
#15 | Drupal_core-ID_autocomplete-2520416-15.patch | 16.17 KB | izus |
#13 | Drupal_core-ID_autocomplete-2520416-13.patch | 15.42 KB | izus |
#11 | Drupal_core-ID_autocomplete-2520416-11.patch | 13.5 KB | izus |
#9 | Drupal_core-ID_autocomplete-2520416-9.patch | 10.82 KB | izus |
#4 | Drupal_core-ID_autocomplete-2520416-4.patch | 1.92 KB | izus |
Comments
Comment #1
LewisNymanComment #2
izus CreditAttribution: izus commentedhi,
here is a patch to add the 'ID:' part
Comment #3
izus CreditAttribution: izus commentedComment #4
izus CreditAttribution: izus commentedmissed the form validation and display in my last patch
Here it is again
Comment #6
izus CreditAttribution: izus commentedComment #7
izus CreditAttribution: izus commentedretrigger testbot
Comment #9
izus CreditAttribution: izus commentedComment #11
izus CreditAttribution: izus commentedComment #13
izus CreditAttribution: izus commentedComment #15
izus CreditAttribution: izus commentedComment #17
pfrenssenThere is another reason to implement this: in Drupal 8 entity IDs are not always numeric, they can also consist of arbitrary strings. We will run into problems when we will try to match on IDs that contain parentheses. The solution proposed here will solve that too.
Comment #18
damiankloip CreditAttribution: damiankloip commentedThe only trouble is this will need a complete re work of how autocomplete.js works, how field widgets work that will use this (to show a different label to what is submitted), and it will break lots of existing autocomplete callbacks implementations as there is no requirement that they are keyed by entity ID currently.
Moving to 8.2.x possibly, but might not be achievable for that either... Not sure.
Comment #20
pfrenssenHaving the entity ID between brackets is also useful sometimes: you might have a bunch of entities with identical titles. Then you can use the entity ID to distinguish between different entities. This is not ideal since the content editors would need to look up and memorize the ID of the entity they are referencing.
Maybe we can implement a new field widget? So we have the standard field widget with the visible entity ID by default, but the site builder can choose to select the widget without ID. This would also solve the backwards compatibility issue with contrib modules that rely on the current behaviour.
Comment #21
pfrenssenThinking a bit further on this, if the entity title by itself is not sufficient to distinguish between two different entities, then we should allow to fully customize the displayed autocomplete values. The ID is very poor to assist with this. It could for example be that the author of the entity is enough to distinguish between two identical titles. Why not show "Identical title (author: Jane Doe)" in this case? There are really nice ways for solving this in a generic way, we could for example provide an autocomplete result view mode!
Comment #22
jibranMoving to right component
Comment #23
BerdirThe widget already supports leaving out the ID *if and only if* there is an exact match for a single entity. Otherwise it doesn't work.
I think this is trying to solve the wrong problem and should be closed as a duplicate of #2346973: Improve usability, accessibility, and scalability of long select lists or a similar issue. When we have a sane autocomplete UI that as a concept of internal key and user-facing label then this problem will simply go away.
Of course, no idea when that will happen, but nothig happened in this issue either for half a year now :)
Comment #27
Pancho@Berdir in #23
Does it? I can’t find the UI setting.
@jonathanshaw in #2346973-140: Improve usability, accessibility, and scalability of long select lists
Agree that it doesn’t seem like we’re getting an autocomplete replacement in core before D9.
So unfortunately we do have to continue fixing the more pressing issues with autocomplete.
Comment #33
schnydszch CreditAttribution: schnydszch commentedHi! Any update to this? Experiencing the same with Drupal 8.8.1.
Comment #34
catchAgreed with Berdir in #23, let's concentrate efforts in #2346973: Improve usability, accessibility, and scalability of long select lists.