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?

CommentFileSizeAuthor
#3 finder-1410862-3.patch1.24 KBfuerst

Comments

danielb’s picture

Yeah 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

fuerst’s picture

One 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?

fuerst’s picture

Status: Active » Needs review
StatusFileSize
new1.24 KB

To illustrate that I attached a patch.

danielb’s picture

I 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?

danielb’s picture

In views/modules/search.views.inc

if you change

  $data['search_index']['keys'] = array(

to

  $data['search_index']['word'] = array(

Does the filter still work? (after views cache clear, and reconfiguring it again)

I can't work out why they chose 'keys'.

fuerst’s picture

Yes, 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 handlers views_handler_argument_search::query() and views_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?

danielb’s picture

Status: Needs review » Needs work

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

danielb’s picture

Category: support » bug
Status: Needs work » Closed (won't fix)

I'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.

danielb’s picture

Status: Closed (won't fix) » Active

I may be willing to add a special case for this.

danielb’s picture

I'm gonna add code like this to 6.x and 7.x

      // Special case, allow search indexes to work. #1410862
      $views_fields['search_index.word'] = $views_fields['search_index.keys'];
      unset($views_fields['search_index.keys']);
danielb’s picture

Status: Active » Fixed

That should do the trick, let me know if it doesn't. Changes will appear in next dev snapshot.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.