Problem/Motivation
Entity Browser should provide a simple way to create views that dynamically limit bundles (including within exposed filters). This would be similar in functionality the default value widget recently added (#2865928: Provide method for views widget to filter based on context), but would live under the "Filters" section of views, and behave like the type filter. An another advantage over 2865928, is it wouldn't require configuration as far as what #widget_context property to use, so it would be more user friendly, IMHO.
Here's a screenshot of me testing default value widget with exposed filter, after creating nodes labeled "Article 1", "Jet 1" and "Shark 1", and set up using entity_browser_test module the widget_context_default_value view, but adding the type filter with exposed option. On the field widget I set the allowed bundles to "shark" and "jet".
You can see the default value widget is limiting the choices, as "Article 1" doesn't appear, but the exposed filter option doesn't limit the choices. I'm not sure that is possible using a default value widget anyway, and is out of scope for a default value widget.

Proposed resolution
Create bundle plugin that reacts to widget_context, that allows exposed filter to also adjust.
When you add the filter, the options are displayed, but disabled:

When exposed filter option enabled, the contextual filter
1) should only show types allowed within #widget_context['target_bundles'] and "all" option
2) "all" option when applied should only show types allowed within #widget_context['target_bundles']
3) If #widget_context['target_bundles'] only has one bundle, hide exposed filter form item.

Remaining tasks
- Review
User interface changes
Adds additional view filter plugin option, when using entity browser display.
API changes
Data model changes
Adds config schema for new views plugin.
| Comment | File | Size | Author |
|---|---|---|---|
| #34 | entity-browser-contextual-bundle-3039038-34.patch | 65.2 KB | oknate |
Comments
Comment #2
oknateHere's an initial patch.
It's dependent on changes to add #widget_context information made in #2865928: Provide method for views widget to filter based on context (built initially with patch in comment 33).
Comment #3
oknateComment #4
oknateThe initial patch I think is awesome and super helpful.
Todo
-
Get "exposed" option working: done!-
Make sure only visible with entity browser view display.done!- test coverage
Comment #5
oknate- Fixed exposed filter option, although I haven't tested some of the options, such as multiple. Some nice features:
- If there is only one bundle available on a field, exposed filter disappears.
Comment #6
oknateOops last post included wrong file, here's the patch. Also, I removed dependency on #2865928: Provide method for views widget to filter based on context (by copying the #widget_context code).
Comment #7
oknateUpdate adds a form alter hook that hides the filter when editing a view display that isn't an entity_browser display.
Comment #8
oknateAdding test coverage. Since this is similar to the default_value view plugin in functionality, it was easy to copy these over and adjust.
Still to do: add test for exposed filter functionality.
Comment #10
oknateComment #11
oknateComment #12
oknateComment #13
oknateComment #14
oknateComment #15
oknateComment #16
oknateComment #17
oknateComment #18
oknateComment #19
oknateComment #20
oknateComment #21
oknateComment #22
oknateAdding tests coverage for exposed filters in field widget, entity embed and inline entity form contexts.
Also, merging in changes from #2865928: Provide method for views widget to filter based on context, which is now in dev.
Note, converts EntityBrowserTest and InlineEntityFormTest to use web driver instead of phantom js, copied from #3040770: Update test classes extending EntityBrowserJavascriptTestBase.
Comment #23
oknateComment #25
oknateComment #26
oknateComment #27
oknatereroll
Comment #28
kellyimagined commented@oknate the patch is failing to apply, see below for the error.
Comment #29
kellyimagined commentedComment #30
oknateHmm, I just tested against the latest dev branches 8.x-2.x and 8.x-1.x and it applied. Can you double check you're using the latest dev branch?
I suspect human error, because it passed on the drupalci testbot 17 hours ago.
Comment #31
kellyimagined commentedThe solution in #30 works great and provides a solution to the issue.
Comment #32
oknateminor changes to EntityBrowserTest, in patch for #27 I had some older code changes, changing those back to the way they are in 8.x-2.x.
Comment #33
berdirshould this have a condition on the entity type actually having a bundle key? e.g. users or paragraph library item might get confused if you try to add this.
you shouldn't inject the actual request but always the stack and get the current request when you need it. While maybe not likely in this context, subrequests result in the current request changing over time.
you can use \Drupal\Core\Entity\EntityType::getBundleLabel() here, then you get for example "Vocabulary" instead of "Term types" which is not a thing. And's it better for translation, e.g. in german it is "Inhaltstyp" and not "Inhalt Typ"
However, there is no plural of that, but that is extremely tricky to properly translate anyway, so maybe you can reword this to avoid the plural?
Just noticed that the parent uses "@entity types" too, I guess that's where it is from. Maybe you can just use the proper label for $this->valueTitle and avoid repeating it in the description? Or just create a core issue to improve the default there.
Comment #34
oknateI addressed the three pointers in #33. Thanks for the feedback, Berdir.
For number #3, I just took out the translatable label:
Comment #35
berdirThanks, didn't test but this is certainly useful and I think ready. Only did a pretty cursory review and a few parts look a bit weird ( that route checks, checkbox disabling and dependency overriding stuff) but I doubt there's a better solution.
Comment #39
oknateSounds good to me. We can improve it later if there is a need.
We have test coverage for field widget, inline entity form and entity embed, so it I think we have good proof that it works, and it's pretty low risk since it's a stand-alone plugin that people would optionally enable.
I'm adding credit to samuel.mortenson as well, since this was built off his work for #2865928: Provide method for views widget to filter based on context.
I'm excited to get this in. On my last project, I created five or six entity browsers for different types of nodes that each had a matching view with different bundles enabled. With this in there, you could have one entity browser and one view that changes contextually. While issue 2865928 did that, it didn't provide a solution for exposed filters. So this is a very helpful tool.
I'll add documentation to the official documentation on how to use these two views plugins soon.
Comment #41
oknateI added documentation on drupal.org. Feel free to review/update.