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.Problem
Entity reference and term reference in particular have the general problem of knowing on not knowing how many options they are referencing too. In case of a vocabulary, it might be 5,20 or hundreds of thousands.
Right now, we have OptionsProviderInterface which those field types implement to provide all possible options to callers, like select widgets. However, if the number of values becomes too high it's not feasible any more to use select widgets, views exposed filter forms or Rules data input widgets.
Also one could argue that having an OptionsProvider does not fit for an autocompleted tag-style vocabulary as usually they are only auto-completed and the set of options is not limitted.
Possible solutions
Let's discuss the approach taken to deal with this situation. I see the following options:
a) Make it configurable. Users can configure for entity reference fields and taxonomy terms whether they should be rendered as select lists, e.g. in views exposed forms. That's the approach taken by ER fields in d7. In addition to exposing new settings, we'd have to come up with an implementation that only provides the options provider for those fields if configured.
b) Extend the interface with a countOptions() method which provides callers with an easy way to check for the number of available options, so the caller can decide whether it's safe / reasonable to make use of the options. E.g., this could be used to select a fitting "default widget" in views exposed filter forms or Rules data input widgets. Also, we could modify the interface to limit the number of returned values by a safe value.
c) Do not deal with it and default to "safe" default widgets where unknown. Easy, but not nice when you get only an autocomplete for a controlled taxonomy vocabulary with 5 entries (e.g. views exposed filter forms).
Comments
Comment #1
fagoComment #2
yched CreditAttribution: yched commented"Allowed values: tricky since CCK D4.7" :-)
De facto, the above would mean splitting the notions of "allowed values used for validation" (possibly large) and "allowed values used for picking one in a list" (necessarily smallish) ?
Comment #3
Bojhan CreditAttribution: Bojhan commentedIs this not all solved by adding Chosen as a select list?
Comment #4
attiks CreditAttribution: attiks commented#3Adding chosen will solve the UI for a little bit, but still requires Drupal to output all select options, so in the case of 100.000, this will be a huge page. Another reason not to output all options is that they might require an entity load/render, if you do this on a couple 1000 items it will be slow.
A combination of chosen with AJAX calls might do the trick.
Comment #5
fago>Is this not all solved by adding Chosen as a select list?
Nope. With chosen you still need to pre-render the huge-list of options and send it to the browser as part of the page what makes no sense for huge lists, and e.g. can let drupal crash due to memory/time constraints (or just slow). However, chosen makes it more complex as with chosen the UX-barrier of huge lists goes away, what makes having big option lists working reasonable far longer.
We already handle allowed-value validation for ER-fields differently, i.e. not based on option lists. Having OptionsList-based allowed-value validation is mostly useful for the typical smallish list, so in cases where it can be both (small or large) decoupling validation and doing it differently makes sense to me - so we are doing fine here already imo.
Comment #6
giorgio79 CreditAttribution: giorgio79 commentedMassive plus for this issue. Core should ensure that the system is scalable, eg a large amount of references can be safely handled. Also, such a solution would render a lot of contrib modules obsolete, such as Flag that uses a separate table for managing relationships. https://github.com/socketwench/flag-drupal8/issues/61
Comment #7
catchComment #14
handkerchiefI have this problem too. And also with SHS or CSHS. I have taxonomy vokubalries with thousends of entries and I can't user another widget then Autocomplete, because it's to large and the website (perfomance) will crack up.
#2829697: Speed up with 30k elements taxonomies?
Comment #15
catchThis has been discussed for a long time but we haven't got far implementing anything for core.
With hierarchical lists, an oldie but goodie (for Drupal 7 and previous) is https://www.drupal.org/project/hierarchical_select.
Comment #16
AnybodyAdd adding #2346973: Improve usability, accessibility, and scalability of long select lists as related because I think both could be solved in combination.
Comment #23
donquixote CreditAttribution: donquixote at European Commission and European Union Institutions, Agencies and Bodies commentedThere are two issues with long select lists:
In my experience, we run into the first problem much earlier than the second problem.