Doug got a start -- this is using the views fastsearch module as a base. he said he ran into some issues with Views 2 but didn't elaborate what the issues where so I'm not quite sure what to do with this.

CommentFileSizeAuthor
#19 views.backlinks.patch2.07 KBmfb
#17 views.backlinks.patch2.2 KBmfb
#17 search.views_default.inc_.txt6.03 KBmfb
#14 views.backlinks.patch1.51 KBmfb
#14 search.views_default.inc_.txt6.03 KBmfb
#4 views2-search.patch9.8 KBjohn morahan
#2 views2-search.patch9.77 KBjohn morahan
search.views_.inc_.txt9.21 KBmerlinofchaos

Comments

merlinofchaos’s picture

merlinofchaos commented
Status: Active » Needs work
john morahan’s picture

john morahan commented
StatusFileSize
new views2-search.patch9.77 KB

Some initial fixes. I'll look at this again tomorrow.

merlinofchaos’s picture

merlinofchaos commented

A couple of quick comments:

The 'user' table is 'users'.

The use of "search_index.score" is not relationship-safe. I realize that with search a relationship may actually be invalid, but let's stick to convention here anyway. In general, you should never refer to a table by its name, but always use the return value from ->add_table or ->ensure_table which will give you the alias that was used.

Oh! And one thing -- views_join always puts {} around the table name. For temporary tables, it turns out this is wrong, so we probably either want a switch or we want to subclass views_join. I suspect we just want a switch since there's a lot of functionality already in there that isn't worth duplicating. That switch would remove the { } processing for temporary tables. I'm not sure this matters for the new search, mind you; I bring this up because it's a problem in Views 1 and D5.

john morahan’s picture

john morahan commented
StatusFileSize
new views2-search.patch9.8 KB

Well, this is still wrong. Specifically, I didn't get around to dealing with the temp tables, and it doesn't use the table alias - when I tried to do this, I discovered that most of views_handler_filter_search::query() doesn't actually work the way it seems to, and I'm not familiar enough with search to easily figure out what they should be doing. Nonetheless, this version does seem to actually work, at least for very simple views.

Requires #242243: add support for HAVING.

merlinofchaos’s picture

merlinofchaos commented
Status: Needs work » Active

I've committed this; but knowing that this isn't fully ready, I'm leaving the issue open.

dmitrig01’s picture

dmitrig01 commented 
+//    $this->query->add_groupby('node.type'); // isn't this the same as search_index.type?

That is bad - you can't always be sure the base table is node, and search_index.type is not node.type.
Search_index.type is 'node' or 'user' or 'advanced_help' (whatever the search hook starts with), node.type is node type.

merlinofchaos’s picture

merlinofchaos commented

Well, the line in question does appear ot be commented out.

mfb’s picture

mfb
they or he
commented

the drupal 6/views 2 version of backlinks is pretty much ready for release -- http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/backlinks/?...

The one thing I noticed is that search.views.inc has some broken code re: search_node_links table, which is defined by backlinks module. This causes some dysfunctional 'Backlinks: Links To' and 'Backlinks: Links From' argument options to appear when backlinks is installed.

merlinofchaos’s picture

merlinofchaos commented

Hmm. The search_node_links table appears to be in core. At least, I don't have the backlinks module on my site at all, but the search_node_links table is in my database.

mfb’s picture

mfb
they or he
commented

Yes, what backlinks provided in drupal 5 was views integration for the search_index table, also part of search module.

merlinofchaos’s picture

merlinofchaos commented

Ahh, so this really ought to be in Views proper, then? (Yes, my ignorance of search's mechanisms knows no bounds)

mfb’s picture

mfb
they or he
commented

That would be fine with me. Take a look at the cvs link above, everything is in the views inc files. If you want to include just the contents of backlinks.views.inc then backlinks module could provide the default views to help non-techies figure out what to do. If you want to include backlinks.views_default.inc too then the module would be phased out.

merlinofchaos’s picture

merlinofchaos commented

How about this: Roll me a patch, it shouldn't be too hard, and I'll take the default views too, assuming they're not overly complex.

mfb’s picture

mfb
they or he
commented
Status: Active » Needs review
StatusFileSize
new search.views_default.inc_.txt6.03 KB
new views.backlinks.patch1.51 KB

This is what I have so far. One question: how would I allow two different columns in search_node_links to be joined on node nid? (this would be needed to provide a forward-links view in addition to backlinks view.)

merlinofchaos’s picture

merlinofchaos commented

To accomplish that, the easiest way would be to create an alias of the table for the alternate join condition. That way from Views perspective they're really two different tables, and you can freely use one variant or the other or both in the same query.

moshe weitzman’s picture

moshe weitzman commented

FYI, the D6 version of search does not use temp tables so we escape that particular need for a little while. OG needs this feature so - subscribe.

mfb’s picture

mfb
they or he
commented
StatusFileSize
new search.views_default.inc_.txt6.03 KB
new views.backlinks.patch2.2 KB

OK this patch handles both forward links and backlinks.

merlinofchaos’s picture

merlinofchaos commented

Just a quick note: I very much prefer this format:

  $data['search_node_links']['to'] = array(
    'title' => t('Links To'),
    'help' => t('Nodes that link to the node'),
    'argument' => array(
      'handler' => 'views_handler_argument_search_node_links_to',
    ),
  );

That way all the *.views.inc files are consistent. Nothing major there.

mfb’s picture

mfb
they or he
commented
StatusFileSize
new views.backlinks.patch2.07 KB

ok I refactored.

merlinofchaos’s picture

merlinofchaos commented
Status: Needs review » Fixed

Committed. Thanks a ton, mfb!

mfb’s picture

mfb
they or he
commented

Great, thanks! It's exciting to see this built in to Views.

If the state of search_node_links was any indication there are probably other problems in search.views.inc. Although these could be fixed in new issues.

merlinofchaos’s picture

merlinofchaos commented

I have no doubt that there are other issues in search, unfortunately. TO fix them I'll have to really get my hands dirty with search and I'm leaving that in the hopes that those who are good at search will take the time to figure out what all is wrong here. =)

But definitely they should be other issues at this point.

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

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

mvc’s picture

mvc
they
Primary language English
Location Montréal, CA
commented
Component: Code » search data
Category: task » support
Status: Closed (fixed) » Active

This is perhaps a stupid question, but how can I actually invoke this code?

I'm using Search: Search Terms as an exposed filter for my View, and expected to see Search: Snippet as a field, but it wasn't there. I added a print statement to template_preprocess_views_view_row_search() to see if it was ever called, but no luck. Then I tried print_r($view) but still couldn't see the snippet anywhere. I finally produced the output I desired by adding this to the row style output template:

$vars['row'] = (object) array('nid' => $fields['nid']->content);
$vars['view'] = (object) array('value' => check_plain($view->exposed_data['keys']));
template_preprocess_views_view_row_search($vars);
print "Snippet: ".$vars['snippet'];

This works fine. But as I aspire to improve my knowledge of views, if there's a better way to do this, I'd love to know. Many thanks.

jferjan’s picture

jferjan commented

subscribing

merlinofchaos’s picture

merlinofchaos commented
Status: Active » Closed (fixed)

The search snippet plugin never actually got finished apparently, so there is some code there but it does not work. That's a separate issue.