Autocomplete limits variations shown to 10 (issue for this module?) [#2231445]

I'm not sure if this issue should be here or entitiy reference.

In a Commerce product display, the autocomplete only gives 10 product variations, and it's not scrollable. So the only way round that is to enter almost the whole title (which is not very 'autocomplete').

How could we fix this? (either through a hack or hook)

I would also class this as a bug given it is likely there would be more than 10 variations.

Comment	File	Size	Author
#12	inline-entity-form-autocomplete-max-result-2185019-12.patch	2.46 KB	rodyk
#12	7.x-1.x: PHP 5.3 & MySQL 5.5, D7 Unable to generate test groups

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

mikeaja CreditAttribution: mikeaja commented 2 April 2014 at 13:27

Title:

Autocomplete limits variations to 10 (issue for this module?)

» Autocomplete limits variations shown to 10 (issue for this module?)

Comment #2

bojanz CreditAttribution: bojanz commented 4 April 2014 at 12:30

Status:

Active

» Closed (works as designed)

IEF's only autocomplete is in the "add existing" form, and it is limited to one entity at a time, so there's no problem here.

Comment #3

mikeaja CreditAttribution: mikeaja commented 4 April 2014 at 17:27

Status:

Closed (works as designed)

» Active

No, that's not what I meant.

Of course you select one variation, but from a list. The list needs to show all variations, not only 10. And you can't scroll through the list.

Surely this isn't works as designed.

Or I am really misunderstanding what you said.

Comment #4

mikeaja CreditAttribution: mikeaja commented 5 April 2014 at 11:05

Let me add to this, because the fact it is not understood suggests it a bigger issue (in the sense that it may have been overlooked).

I think either two solutions could work here:

1) simply no limit, so all variations are shown in the list (otherwise it is not possible to select a variation that is not in the first 10)

2) or, make the autocomplete list only show variations that do not yet connected to the product display (so the list of 10 are only those not already added).

I need to fix this now for current site as adding variations is a pain with the list limit. Any pointers to help?

Comment #5

DanielFriis CreditAttribution: DanielFriis commented 14 August 2014 at 13:58

@mikeaja: Number two isn't optimal I think, at least not when you have many nodes with the same or similar names. I cannot see why all the matches couldn't be listed though. Performance is really not an issue when you can't even use the feature.

I'd also like to see a fix for this. I'm currently working with a site where we've ended up with 50 nodes called "References". Makes it impossible to choose the correct one. The best option would be to be able to enter the NID, would that need a core patch?

Comment #6

mikeaja CreditAttribution: mikeaja commented 19 August 2014 at 19:29

@DanielFriis

Well I'm very glad someone else can see this issue. When I get a chance I will look at option 1 then.

Comment #7

potassiumchloride CreditAttribution: potassiumchloride commented 24 September 2014 at 18:27

I think that any field that utilizes the autocomplete widget shows only 10 results. The same is true for the regular Entity Reference field if you use the autocomplete widget. To change the widget from 10 something else, you need a custom module.

See http://drupal.stackexchange.com/questions/68566/how-to-show-all-autocomp... and http://drupal.stackexchange.com/questions/101781/control-number-of-autoc....

Comment #8

mikeaja CreditAttribution: mikeaja commented 25 September 2014 at 08:39

Thanks for you adding your thoughts to this. The limit to 10 is not the main issue though. It is the fact that already selected items are still shown, there some variations cannot be accessed easily.

If you have say 20 product variations, starting with 'T shirt with cool design and logo' and ending with the colour, then there is no way to access the final 10, unless you type in almost the whole name in the autocomplete (which is not productive).

This is a massive put-off for commerce as the scenario above is not uncommon. I'm not saying anyone should rush and fix it, I'm just surprised there are not more that see the issue here. Having worked around another open-source project, I've seen how often users get to these types of things, and see a barrier that they did not expect, and don't get more invested in the project. I believe Commerce will suffer a lot from this.

Of course, I agree that a developer can create their own custom module. I've got around this by not using inline variation adding (which is not ideal, but I could never give a client that autocomplete as it is, and the job does not warrant a custom module at this stage).

Comment #9

simohell CreditAttribution: simohell commented 7 March 2016 at 16:51

The biggest problem is that the fixed limit can make any number of entities completely unreferenceable.

This is a case where the title is a substring matching 10 or more existing titles, that are listed at the top of list.

How this should work, I think, is that if the substring matches the complete title, those results should be listed at the top of the shortlist. (This works assuming nobody uses the same title in more than 10 different entities, in which case there would still be a problem. I almost any case that would be a silly thing to do anyway.)

Comment #10

cydharttha CreditAttribution: cydharttha commented 26 August 2016 at 15:24

I don't know if it will help in the specific case of commerce, but I am currently modifying entityreference.module to increase number of results returned. entityreference_autocomplete_callback_get_matches() is the function where the return limit is set:

http://www.drupalcontrib.org/api/drupal/contributions%21entityreference%...

You'll see it in the call to getReferencableEntities().