Views EntityReference filter: Add functionality to switch from select to autocomplete widget when a max number of options reached

I have added MR 9866 to add this feature. Code was inspired by functionality that existed in https://www.drupal.org/files/issues/2020-09-30/2429699-351--on-9_1_x.patch → on 📌 Add Views EntityReference filter to be available for all entity reference fields Closed: duplicate .

Another reminder that you MUST follow the instruction on ✨ Continuation Add Views EntityReference filter to be available for all entity reference fields Active under the "How to use" heading to set up the EntityReference filter first for this to work.

Thanks for adding test coverage. For the new schema change will need an upgrade path for existing and test coverage for that update.

Hey! I'm writing this comment after reading that one of the remaining tasks is to get feedback from the community. I find this feature quite useful. In fact, in one of the projects I'm working on, there is a need to increase the maximum number of items in an exposed filter that contains many countries. I believe that the functionality provided here provides both increasing that limit in the views you want, as well as making future filters that exceed that limit in other views automatically have the autocomplete widget.

Example for unlimited items: 3481590-unlimited_items.png
Example with the limit set to 100 items: 3481590-limit-set-to-100-items.png

+1 for this functionality to be added in core. Tested this and it works fine, it switches to autocomplete when list in the select box exceeds the limit

Coming from https://www.drupal.org/project/drupal/issues/3347343 ✨ Continuation Add Views EntityReference filter to be available for all entity reference fields Active , does anyone recall the decision to make it 100 static? What kind of performance and ux issues were being experienced to warrant this limit? Should we be providing an override if the consequences are severe?

Added upgrade path and upgrade path tests. Back to NR.

@dimaro - Thanks for the bug fix and the review.

@joewhitsitt - I don't recall where 100 came from. I am assuming it was a "good guess" but I could be wrong and some testing was done. Regardless, this MR will enable the developer to set it to whatever value works for them based on their server resources and site configuration.

I have also added a 10.5.x version as a patch from the 11.x won't apply to D10 due to ViewsConfigUpdater not being a Service yet.

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 necessarily 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.

Failing test is related to 🐛 [10.5.x] test DB transaction isolation set to read-committed breaks tests Active . Setting back to NR.

smustgrave → changed the visibility of the branch 3481590-views-entityreference-filter_10.5.x to hidden.

Problem was the bot was looking at the latest MR and checking it against 11.x so I hid it for now

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 necessarily 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.

Thanks smustgrave! Trying again to see if the bot is now ok with NR.

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 necessarily 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.

There is a bug in the current MR when the filter operator is exposed.

Error:
TypeError: Cannot access offset of type string on string in Drupal\views\Plugin\views\filter\EntityReference->validateExposed() (line 681 of core/modules/views/src/Plugin/views/filter/EntityReference.php).

Steps to reproduce:

1. Follow the IS Steps to reproduce to create a View with an Entity Reference filter using the select widget.
2. Apply the MR patch
3. Edit the Entity Reference filter settings (via the Settings link beside the filter):
1. Ensure the Selection type is set to Select list
2. Ensure the Maximum entities in select list is set to more than the number of nodes created. We don't want the widget to switch to auto-complete to reproduce this bug.
4. Modify Entity Reference filter configuration (via the filter link):
1. Check Expose operator to expose the filter operator.
2. Check Allow multiple selections
5. Save the view
6. When viewing the view set the Operator to Is one of and select one of the values
7. Press Filter
8. Actual result: The above error is thrown
9. Expected result: The view results should be correctly filtered.

Given we are modifying EntityReference::validateExposed we should add more comprehensive testing when the operator is and isn't exposed and the different filter widget configurations.

Working on this now.

I have pushed more comprehensive testing, of which some will fail due to the bug mentioned in #21.

I have pushed the fix. Needed to account for the element being within a wrapper when the operator is exposed.

Back to NR.

tame4tex → changed the visibility of the branch 3481590-views-entityreference-filter_10.5.x to active.