UX: Hide entity ID in autocomplete widget

There's already an issue to add select2 to core which, once committed, will solve this.

#2346973: Improve usability, accessibility, and scalability of long select lists

Yes. YES, dammit. We need this, really badly.

I have given this a bit of thought and I have a backwards-compatible solution in mind. The normal entity reference autocomplete text field is encapsulated by the EntityAutocomplete form element, so I think we should alter this element to produce two sub-elements: the text field which does the autocompleting (core textfields support auto-complete as a matter of course), and a hidden field that holds the target entity ID, and whose value would be set by some JavaScript. Autocomplete obviously already requires JavaScript to work, so I don't think this should be an issue for non-JS people.

To support non-JS people and maintain backwards compatibility, the entity reference textfield would continue to support specifying the entity ID in parentheses. On the backend, the element would search first for a value in the hidden field, then for a value in parentheses in the text field. This would maintain perfect backwards compatibility.

I'm willing to give that approach a shot if this sounds OK to people. Maybe we could fix this initially for the standard single-value entity reference autocomplete textfields before fixing it for multi-value (tags) textfields? I'm open to suggestions there...

EDIT: It'd be nice to land Select2 in core, but last I heard, it had some serious accessibility issues that might block that from ever happening. The idea I just proposed might at least make for a nice short-term solution.

#7 In the case of hierarchical hierarchy we use the following solution, we render all options including the parents in 1 item, this in combination with something like select2 allows user to easily find what they need.

Vehicle > Motorbike > Honda
Vehicle > Car > Honda

Real life example

I think we have several problems here:

1. Users don't know what those numbers in brackets are. If anything they look like the item count in a search, especially for taxonomy terms where you could have 123 items or so.
2. Users can't always distinguish two entities on their title/name alone: It could be Georgia the country or Georgia the US state, two images can have the same title, or the same band playing at a venue several times... In this cases the ID helps, especially if other admin pages have been configured to display IDs. But users only see the ID after they have already selected an entity, and might need to go through several rounds of picking one to get the correct one.
3. Site builders have no way of configuring the display of title and ID in the list, so they aren't able to exclude or hide the ID if it's appropriate for a specific site.

Adding something in the description text works, but we shouldn't need to rely on site builders to provide explanation to the end users on how the UI works, and on a site with several entity references that's time consuming, and might need translations...

Could we add a span tag around the ID? That way it would be possible to hide the display of the number with CSS at least? Also not very elegant because it would require changing the admin theme.

Thinking much bigger: Ideally I would like to have an option to toggle whether the ID is displayed or not. And I would like users to be able to reference an entity by its ID instead of by its title.

IMHO, there are two major problems we need to solve here:

1. Once an entity is selected, the user sees the ID and they feel the ol' WTF.

2. All entities are presented in the autocomplete results in exactly the same way (the label, and nothing else). Depending on the circumstances, this results in the possibility of the users selecting the wrong thing. Showing the ID does absolutely nothing to mitigate this problem -- normal users don't know or care what the IDs are. They recognize what they want by its title, date, teaser text, author picture, etc. Or some combination thereof. Anything, really, but the ID.

Of these two overarching issues, I think #2 is by far the more severe one. Showing the ID is definitely weird, and it's poor UX, but it's also relatively easy to explain away (as others have pointed out). But not having a way to know exactly what you're selecting is a major problem. I think we should attack that first, then think about ways to hide the ID.

I love to offer ideas for technical fixes, so here's one: what if we make the autocomplete results themeable? We could simply introduce theme hooks, varying by entity type: theme_entity_reference_autocomplete_result__node(), theme_entity_reference_autocomplete_result__taxonomy_term(), and so forth. Then each entity type could be presented differently in autocomplete results, which would make it MUCH easier for the user to know what they were choosing -- and this would be helpful to site builders and themers too, since they could customize this stuff in the theme layer. At that point, users might still see the ID, but I bet they won't care as much, because they will be far more confident that they have chosen the correct thing.

This is a problem space that has been attacked before -- Entity Browser is an attempt to build a hyper-generic, super-abstracted, incredibly far-reaching API to solve these very issues -- but I think core should have more modest ambitions, at least for now. Improving the autocomplete results would be a giant UX win which I think would put the "should we hide the ID?" question into proper perspective.

I am so happy to see this issue being opened, because this is certainly an issue I've run into with clients over the years. So yes, I'm a fan of this being discussed :)

I like #8's suggestion of displaying the context by which the term is being used, so users can correctly pick the result they want. In my experience, users don't typically use the ID to determine the correct result, so providing a better context will help so much more.

I also like #10's suggestion of making autocomplete results themeable. I do think being able to provide *some* sort of context in some way is important, and adding date, teasers, etc to the result would help this as well.

Either way, something else besides IDs should be used to help users choose the correct result, and the above suggestions would definitely solve that problem.

Whether users are aware of the ID or not depends on how the site is set up.
Where the ID is used in the admin interface it becomes a straight forward way of identifying an entity.

Theming option can indeed help to provide context, but not for all entities it's a straight forward as with taxonomy terms and their hierarchy.

See the following screenshots: That's two images from the same event, where the editor of the site has used the same title (which will be displayed as caption). The editors know the ID because it's displayed in the media library of the site, so they know whether they have chosen the correct one, but it would help them if they would already see the ID number earlier.

Site builders have no way of configuring the display of title and ID in the list, so they aren't able to exclude or hide the ID if it's appropriate for a specific site.

I'm sorry but this is not really true. Site builders can use and configure the Views selection handler to customize what is being displayed in the list, which was designed and written to fix exactly this problem, that in some cases the entity label alone does not provide enough context for users.

Discussed #15 a bit with @ifrik on IRC and we decided to postpone this issue on #2174633: View output is not used for entityreference options, because that issue will actually make what I said above possible.

I like the suggestion in #5 for single valued fields.

Entity ID's and ID's in general are internal reference keys and users should:

A) Not be expected to know what they are
B) Be expected to be confused/thrown off by them

I also think it's pretty straightforward that the "label" is what they want users to see and the "value" is what the server-side/backend is going to operate on. It seems logically inconsistent to use the "value" as the display for the field once selected instead of the label, but I completely understand why (where else does the value go?).

The obvious workaround that comes to mind for UI purposes would be to store the actual value in a hidden field, and put the label in the textfield that's displayed to the user, but I am not certain how easy it is to incorporate.

We actually have a custom AJAX autocompleteselect callback that pulls the value off the $form_state for the field, sets it in the $form storage, and then re-sets the userInput and value for the field on the $form_state to what the label is. The only problem with this approach is that for a split-second the user still sees the raw value instead of the label, as the AJAX is being performed (and apparently that's still really confusing).

@amateescu I tried the patch from the issue you were pointing at, it helps to change the value in the field by changing the view but I have not figure out how to hide the ID. Is it possible to do with some options?

#2174633: View output is not used for entityreference options is in now.

Opened #3088348: Autocomplete appends value instead of label in element.

Actually, what should have in autocomplete is to be able to find references by ID, because there is a sites as it is the case I am working on is that the title of the publication is repeated many times what makes it unbearable to try to guess what it is. Since the title is not accompanied in autocomplete of the taxonomies that differentiate it. So it is easier to put the link of that publication than to use the reference.
As it works now, its use is limited to those articles or blog sites that have all different titles.

@maria.dis, there's a contrib module for that called autocomplete_id.

This issue persists as a fairly significant UX issue. Drupal needs to be able to work well for users that are neither site nor content administrators. For them, the appearance of the entity ID in autoselect forms is completely extraneous in most cases. The contrib modules chosen and select2 do resolve the issue for select lists. The problem with using a select list widget instead of autocomplete is that the placeholder text for an optional field is "- None -" which is also not easily customizable--a separate UX issue for select lists. But this thread is about the autocomplete widget, and there is still not a solution. Displaying website codes that add visual noise and can confuse front end users should at most be optional, and definitely not required by default. I suggest changing the issue to a bug report.

I wish there was a way to hide taxonomy term ID to the front end user. No need for it.

@tepelena You could try Autocomplete Deluxe

In order to remove the Taxonomy Term Id in autocomplete using jQuery for the time being.

(function($, Drupal, drupalSettings){
  'use strict';

  Drupal.behaviors.common = {
    attach: function(context) {
      // Remove TID's onload.
      Drupal.common.remove_tid();

      // Remove TID's onchange.
      jQuery('body').find('.form-autocomplete').on('autocompleteclose', function() {
        Drupal.common.remove_tid();
      });
    }
  };

  Drupal.common = {
    remove_tid: function () {
      var field_autocomplete = jQuery('body').find('.form-autocomplete');
      field_autocomplete.each(function (event, node) {
        var val = $(this).val();
        var match = val.match(/\s\(.*?\)/g);
        if (match) {
          $(this).data('real-value', val);
          $(this).val(val.replace(/\s\(.*?\)/g, '' ));
        }
      });
    }
  };
})(jQuery, Drupal, drupalSettings);

Code Credit Goes to the commenters in (https://drupal.stackexchange.com) issue:
Hide the term id on autocomplete widget

To avoid scope problems with this JS it's better to use let and const.

Keep in mind that by removing id with js, EntityAutocomplete's extractEntityIdFromAutocompleteInput will not return any matches and validation will fall to matchEntityByTitle.
If you don't use title as Option label (e.g. if you use Entity Reference View to show more fields at the options) this will result in field not validating unless you write custom validation using the "real-value".

Just ran into this is the media library where our customer wondered, why the media library returns 139 results, while the number in brackets shows "(58)".

At least describing the value in brackets clearer, like "Term name [ID: 123]" would help a lot without huge technical modifications!
I added that as possible resolution / workaround!

Any plan how to proceed here? I think first we need a plan?

I agree, "(ID: 69)" would be much clearer

Found this looking for the fix as well. Doesnt seem like much headway here other than a lot of related posts (going through next).

One thing though, not sure how clear it is made here but there are 2 different issues here (shown in #14):
1. the autocomplete result set shows the ID value; but this is easily fixed using Views
2. the selected result that ends up shown as the field value shows the ID (regardless of what is done in Views). This is when filling out the form or on edit. This is the part that needs to be fixed.

I think it's important that the developer has an easy way to hide the IDs from the users.

Hi,

I'm here because this is not only an interface problem: we have users that have managed to change the node ID and Drupal does not throw an error.

1 We have a field that uses an entity reference with autocomplete (because there are more than 1000 nodes to choose from). Hence, Drupal accepts any entity type in this field.
2 In the entity reference view, there is a filter on node type being a specific type.
3 the user searches for a node, finds it, and the field is filled with: "node title (1234)"
4 our user changes the ID, now we have: "node title (123)"
5 Drupal saves the node ID from the autocomplete field without checks or error. The field references "some other nodes title" with id 123.

This is really annoying, and impossible to clean up: what node was meant to be referenced?

It doesn't make sense to display an ID: users don't know or think in IDs. Entities with duplicate titles don't justify this behaviour: they should not have duplicate titles. I'm very glad this is an active topic, and I hope that it gets fixed. This should have been fixed a long time ago, because nothing is worse than users being able to give invalidated input. Please add this problem to the motivation.

Changed category from 'plan' to bug report, because it's not only a UX problem

Changed priority according to guidelines:
"Major bugs include those that:
... Cause user input to be lost, but do not delete or corrupt existing data."

Because changes to the exposed id at the end of the autocomplete cause another entity to be referenced, without possibility to recover the original input that the user did while looking up the entity.

While I don't agree with the interpretations in #48 used to justify changing the category to Bug report and the priority to Major, there's not much reason IMO to change them back. For better or worse, changing the category/status does not increase the likelihood of progress happening here. There aren't contributors waiting for sufficient justification to tackle this, someone just has to do it. 6 years in I don't think theres much chance of anything happening without a patch or MR that offers a possible solution - even if it's a rough first draft. Even if it's not ultimately the correct solution, it will serve as a spark to get things moving again.

Tagging for review at a future usability meeting.

Adding #3222995: Implement chips based autocomplete designs with the design proposal for Claro as a related issue.

This adds a "Show IDs" setting to the formatter that defaults to TRUE, which would be the current experience, but when set to FALSE, it does not show the ids. It's possible that's not the exact implementation that will be wanted, but the raw ingredients are all there now and can be tweaked to whatever decision is ultimately made. (in other words, this should still get usability review, but the chosen direction will likely be some variation of this patch).

There's also @todo in the JS that would need to be taken care of.

Because this adds a schema setting I suspect some existing tests might fail now, they'd need to be updated to reflect the new changes.

For some version of this to get committed, there would need to be test coverage for the new "Show IDs" setting. There seems to be enough enthusiasm behind this issue for someone to jump in and add those.

To anyone manually trying this out, remember the default setting is to show the ids, so the field formatter setting must be changed to hide the ids.

Hi,

Regarding usability we can now put anything in the entity reference, and thanks to the id, Drupal can easily link the entity that we wanted.

Without id, the current implementation falls back to matching which may prove to be problem. So it looks preferable to me to keep the id, but make it invisible.

The ID needs to be tied behind the scenes to each option being shown. Once selected, the ID can be stored behind the scenes as the value of the form element, and the item's label can be displayed without the ID. Is that correct?

Did some initial manual test and noticed that we might still need to update the text for the summary of the autocomplete widget.

With this patch, even when Show IDs is set to false, they will still appear if there are duplicate titles. I imagine distinguishing duplicate titles was why this was added to begin with, and this provides the benefits of that without the added (id) noise when it isn't needed.

I imagine most users will be able to intuit why the ids are present as they'll only be there when there are visibly duplicate titles. It's basically the recognition pattern when a movie remake/common title has the release year next to it such as "A Nightmare on Elm Street (2010) / A Nightmare on Elm Street (1984)".

Switching to NR but aware it still needs tests. Implementation may as well get reviewed to keep things moving, and I'll hope at least one of the 90+ followers on this issue are interested enough to see this land to chip in and add tests. Even if the implementation changes, the tests would require very few changes, if any.

Testing on 11.x

On the Article node form
When "Show entity IDs" is unchecked the description text says it's True. Bug

Creating an Article with the show IDs unchecked, the id doesn't appear.
Creating an Article with the show IDs checked, the id does appear correctly.

Also will need an upgrade path I imagine.

I agree with adding something to distinguish between duplicates.

My only concern is that to a user the numbers could look quite arbitrary and they may wonder why these numbers simply don't just start from 1.

The problem we may have here is that this look very similar to what Windows and other operating systems do with duplicate file names, they add a number after the file name which starts incrementing from 1 or 2. Because of how establish of a pattern that is, users may be surprised that the numbers after the duplicates do not appear to be in a logical order incrementing from 1. A user may expect for example:

hello (1)
hello (2)
hello (3)

We don't tend to train users to think about entity IDs, so they may not understand what the number relates to, especially when you consider that users will likely never see entity IDs anywhere in the UI; With the only notable except being in the URL, but a user likely isn't paying attention to what is in the URL, and even if they do they might not be the one creating the entities which appear in the list or they might not relate the ID in the URL to the number in the list. So, the user may not have any frame of reference nor way of actually understanding what the difference is between the duplicate entries. As a user if I've never seen these IDs before, how do I know if the one I'm linking to is actually the correct one.

At least right now we consistently display the entity ID for all items in the list, and yes displaying the ID to begin with also isn't great, and the problems I described above about lacking a frame of reference are still applicable, but I would argue that a consistent approach is better UX then an inconsistent approach. At least displaying the IDs for all items in the list, not just duplicates, does not imply the pattern which I described of auto incrementing numbers for duplicate file names.

It still should be optional overall or at least per-element, because there are plenty of times where I know I don't have duplicates, or where I have distinguished between duplicates by appending/including more meaningful information in the label.

I'm honestly fine with seeing the IDs in the admin interface, but without a way to hide the IDs for the end-users, that's frustrating to me.

Linkit module (https://www.drupal.org/project/linkit) uses its own autocomplete field in the widget and offers the option to use tokens to add metadata. That works quite well.

So another option, if we ensure wer're always able to identify the selection despite the test, might be to use the label + id just like before and add a hook for contrib or an "Extended" option in core which allows to use tokens for the options text. Default would then be sth. like "[entity:title] ([entity:id])". Still we'd have to ensure that the chosen result can be identified in the background...
If we decide to do something like that, we should also discuss if a metadata-line like in Linkit should also be possible. At least in contrib.

Have a try with Linkit, it's really flexible and helpful.

How far should we go here?

How far should we go here?

Good question.

1. To reduce the confusion, turning (123) into (ID:123) would already be a useful tweak.
2. Forcing to show it in case of duplicates seems like the right thing to do. Adding the "id: " bit would also address the concerns in #60, no?
3. The UI in #52 look very reasonable to me. Since this issue was always about hiding that confusing ID it would probably have to be unchecked by default :)
4. Could the code in #52 be made such that it *supports* contrib in doing the fun things outlined in #62?

I like the ideas in #62.

I think it's important that whatever solution is created, the ID of the item selected should not be determined/inferred from the text in the autocomplete. Users can change the text that is entered in the autocomplete element after selecting an item, so getting the correct ID from it cannot be relied upon.

To reduce the confusion, turning (123) into (ID:123) would already be a useful tweak.
Forcing to show it in case of duplicates seems like the right thing to do. Adding the "id: " bit would also address the concerns in #60, no?

Yeah that could be a good way of mitigating the problem.

Also +1 to the idea in #62, there may even be some other unique identifier that the referenced entity uses which is more appropriate. Giving that flexibility could be useful in a number of different situations I would think.

Patch for 9.5

Can we define a pragmatic approach that covers items 1 to 3 in #63, and establish what's needed to add the *hook for contrib* as suggested in #62?

Then, lets figure out if both can be done in this single issue here or if the hook for contrib part should be a separate ticket.

Compatible with Drupal 9.5 and PHP 8.1
Hide ID for view filter autocomplete

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Reroll against 11.x

The Needs Review Queue Bot tested this issue.

While you are making the above changes, we recommend that you convert this patch to a merge request. Merge requests are preferred over patches. Be sure to hide the old patch files as well. (Converting an issue to a merge request without other contributions to the issue will not receive credit.)

Do we already have a solution for this since this post from 2017 but I am still looking for a way to hide the term ID on the autocomplete field, please advise, thanks

This patch is not working with Custom References.

Even if I remove the ID, it still appears There are no users matching or There are no content matching when I save the user or the node with custom reference

Patch in #70 has another issue - when using with taxonomy terms, and a term has comma in the name, it can't find the term to use in filters.

E.g. say there is a term with the name set to "TERM NAME, WITH COMMA". When using exposed autocomplete filter, and choosing this term, it reports back an error: There are no taxonomy terms matching "TERM NAME". - it strips everything after the comma.

To add to my comment above - when Autocomplete used as the widget for exposed filter in Views - it treats passed in values as a list of tags, and considers "," as a separator. With the absence of ID value, it looks up entities by name/title, which obviously fails, should entity name/title contain comma.