When configuring sort options for a view, i want expose some fields that do not sort granularly -- for example boolean flags like published or promoted.
So, I also need to add an additional sort option, which is not exposed, to implement a "fallback" sort.
In essence, what I need is something like:
"select * from node order by status DESC, created ASC"
In the example above, the fallback sort is on node.created.
However, if an additional node.created is added as exposed sort, the fallback overrides it and the exposed is ignored.
Exposed sort, if its field conflicts with any non-exposed sort, should override the non-exposed sort.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | search_api_views-handler_sort_respect_default-2145547.patch | 743 bytes | aaronbauman |
Comments
Comment #1
aaronbaumanI ran into this error specifically with search_api_views
Don't know if it's also a problem with views core or not.
The attach patch ensures that, if there are multiple sorts configured for the same field, the former-most will take precedence.
Comment #2
drunken monkeyThanks for reporting this, and sorry I apparently completely overlooked it until now.
I just tested, and it doesn't work with normal Views (e.g., on Content), either. So I guess this should be fixed in Views, or in both (if we have to fix it in the sort handler).
Thanks a lot for your patch, though, it works perfectly! I've now committed it as a (hopefully temporary) workaround.