Currently, we always use the Master display for building the view when we want to execute an autocomplete query for one. This can lead to wrong settings being used.
The easiest way to fix this is to just let users select which display should be used. This isn't ideal, but determining the right display would be very tricky, and would also have less flexibility in some aspects.
One other thing the patch in comment 1 addresses is to document the lack of support for contextual filters / arguments. As views can receive their arguments from virtually anywhere, and the context in which we execute the autocomplete query is very different from the one in which the corresponding view is normally executed, there is really no way to reliably support any portion of this functionality. Therefore, I opted to just clearly document this shortcoming and encourage users to use a display without contextual filters as the base for the autocomplete query. (The problem here is, also, that the view might receive wrong arguments and/or return no results at all due to validation errors – even if just skipping the arguments would be unproblematic.)
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | 1803150--views_display_option-1.patch | 6.67 KB | drunken monkey |
Comments
Comment #1
drunken monkeyComment #2
mh86 commentedThanks for the patch, Thomas!
The ability to select the views display is great. There might be some rare (or crazy) use cases, where you have a separate autocomplete display that does some special filtering (e.g. only promoted nodes).
Code basically looks good, the only thing I don't like are calls like "$views_id = substr($search->machine_name, 17);", and you are using them quite often. Maybe one function for that would be useful, but that's a different topic.
Marking as RTBC, as everything seems to work.
And it should be noted that this patch also introduces a small API change: the search id query option has been changed from 'search_api_autocomplete' to 'search_api_autocomplete:' . $search->machine_name and I think I've already implemented this specific search id somewhere.
Comment #3
drunken monkeyOh, you're right, should have noted that. I guess this might mess with some facet settings (although these don't affect the query anyways) and local customizations …
Anyways, thanks for testing!
Committed.