Currently it is not possible to use the Search Index as an element in a Views Finder. Reason is the search_index Views field is named keys but the real database table field is word.
By hacking finder/modules/finder_views/finder_views.module it is possible to get it working though:
--- a/sites/default/modules/finder/modules/finder_views/finder_views.module
+++ b/sites/default/modules/finder/modules/finder_views/finder_views.module
@@ -280,6 +280,10 @@ function finder_views_finder_fields($finder, $finder_element_id) {
$base_tables = $view->get_base_tables();
$options = views_fetch_fields(array_keys($base_tables), 'filter');
foreach ($options as $k => $v) {
+ if ('search_index.keys' == $k) {
+ unset($options[$k]);
+ $k = 'search_index.word';
+ }
$options[$k] = $v['group'] .': '. $v['title'];
This is rather a quick hack than a long term solution. Any ideas to solve it properly?
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | finder-1410862-3.patch | 1.24 KB | fuerst |
Comments
Comment #1
danielb commentedYeah I'm not keen to hack in special support for a particular field. So if you could figure out a more generic way to do it, that would be good.
There isn't really any documentation available for how to integrate with Views, so most of that stuff is just a guess :D
Comment #2
fuerst commentedOne way would be an override using a Drupal variable which can be populated by people who know about the problem. This way you do not need to hard code this kind of work arounds. Your users although do not need to hack the module when working around. Would that be something you may support?
Comment #3
fuerst commentedTo illustrate that I attached a patch.
Comment #4
danielb commentedI guess, but I'm thinking Views has a way to work this out - otherwise views wouldn't work, so how can we tap into that?
Comment #5
danielb commentedIn views/modules/search.views.inc
if you change
to
Does the filter still work? (after views cache clear, and reconfiguring it again)
I can't work out why they chose 'keys'.
Comment #6
fuerst commentedYes, after changing key to word in
search_views_data(), clearing Views cache and reconfiguring the Finder element in question it works.Don't know why they choose key too: In
search_views_data()the field is called$data['search_index']['keys']but in the Views handlersviews_handler_argument_search::query()andviews_handler_filter_search::query()the table field word is used. May be key is used for historical reasons but even back in Drupal 4.6 the field was called word.Not being a Views guru it looks like it is necessary to work around this, doesn't it?
Comment #7
danielb commentedThanks for checking that out. I am a bit lost as to what to do though.
I've requested support here #1426666: search_index.keys => search_index.word ?
A lot of assumptions have been made integrating with Views, so I don't really know where we stand on how to handle this.
Comment #8
danielb commentedI'm afraid this is a bug that won't fix from the looks of the response in that other issue.
The design of this module assumes tablename.fieldname is the key of the filter, but apparently that isn't always the case.
You may be able to use a computed field to work around this problem as described on the project page.
If anyone can suggest how to retool this module to determine the correct table.field, please do.
Comment #9
danielb commentedI may be willing to add a special case for this.
Comment #10
danielb commentedI'm gonna add code like this to 6.x and 7.x
Comment #11
danielb commentedThat should do the trick, let me know if it doesn't. Changes will appear in next dev snapshot.