Views integration

I'm having trouble imagining how that would work. Do you mean a similar nodes to the content of a view, similar views to the content of a view, or putting the content of the similar block into the content area of a node?

Hi, I am interested too in doing such a thing (Creating a view where we can filter nodes so that the list of Similar nodes can be retrieved)
As the module has not been updated in a bit less than a year, I thought I could try and integrate it to Views.
However, I'm a pure newbie, and the tutorials, yet simple, look helpless.

I keep you informed.

Simple Nasty Hack:

STEP 1: Insert something like this into your node template:

$similarblock = similar_block('view', 0, $node);
if($similarblock['content']) {
  echo "<div class='similar'>";
    echo 'SIMILAR NODES<br>';
    echo $similarblock['content'];
  echo '</div>';
}

STEP 2: Open up similar.module in your text editor. Look for the function called similar_block(). You will see that there is no dedicated response to case "view". We are going to create one. First, copy the entire chunk of code for the default case. Then paste it in between the case "view" line and the default: line. Then replace the whole first if/else clause (i.e., 6 lines) with this single line: $node = $edit;. The result should look like this:

case 'view': // HACK BEGINS HERE
  $node = $edit;
  $similar_node_types = variable_get('similar_node_types', _similar_published_node_types());
  if ($node->nid > 0 && !empty($similar_node_types[$node->type])) {
  unset($similar_node_types);
  switch ($delta) {
    case 0:
    // The subject is displayed at the top of the block. Note that it should
    // be passed through t() for translation.
    $block['subject'] = t('Similar entries');
    $cache_blocks = variable_get('similar_cache', SIMILAR_CACHE_DISABLED);
    if ($cache_blocks) {
      $cached_content = cache_get("similar_block_0:$node->nid", 'cache');
      if ($cached_content === 0) { // cache_get() only returns 0 when data is not returned for the key
      $block['content'] = theme('similar_content', $node);
      $lifetime = variable_get('similar_cache_lifetime', SIMILAR_CACHE_LIFETIME);
      cache_set("similar_block_0:$node->nid", $block['content'], 'cache', $lifetime ? time() + $lifetime : CACHE_TEMPORARY);
      } else {
      $block['content'] = $cached_content->data;
      }
    } else {
      $block['content'] = theme('similar_content', $node);
    }
  }
  }
  return empty($block['content']) ? '' : $block;
  break;

default: // ORIGINAL CODE RESUMES HERE

NOTE: This is guaranteed to add load time and overhead to your view. This overhead could be significant on a page with many nodes, especially if the similar results for those nodes haven't been cached yet. But it works. YMMV.

Subscribe, a less expensive version would be nice.

The custom similar caching code was removed in 6.x-1.1, so the above patch won't work.

A great module.

Is there any way of re-instituting Views support? The patch works very well, but can it be wrapped into a secondary module, so we can upgrade Similar Entries.

Note: Similar Entries plus the Views patch is the only way I know to show related content in a View. If there is any other way of handling this, I'd love to know.

+1

The way to get it to work is to provide the list of nodes that are similar to the current one, and then with Views we can modify the output, for example to output teaser, teaser with image etc etc.

Just found this http://drupal.org/project/similarity it seems to have Views support

Unfortunately, it looks like Similarity is not under development, and nor is it being supported...

I like this module, also wondering about some kind of views integration.
I would like to see filters like:

Similar entries:Title
Similar entries:Body

So We could list similar nodes according to body and or title. combining with http://drupal.org/project/similarterms module we could have a rather good listing of similar nodes.

Hi. I have just taken over development of this module and fully support the idea of integrating it with Views. However, at the moment my focus is on clearing out the queue. Bug reports have to be addressed first, and then I will decide on and work on Views integration. I use similar by terms on my own projects sometimes, and I think views support is the biggest benefit of the module. Depending on how progress is being made on the D7 port, the next version of this module may depend only on Views and provide default views for blocks instead of using hook_block() family hooks. If that is the case then the Views integration will still be back ported to D6 but the regular blocks will remain.

If anyone wants to see this feature implemented sooner rather than later and wants to provide patches for Views integration I'm happy to commit any good work.

I thought I would come back and mention what progress has been made. This issue is going to be used to track progress on Views integration.

The 6.x branch of Similar entries has been fully integrated with Views 2, and I intend to have it in a dev release here soon. Actually, it's going to be a new version of the module, version 2. This is mostly because there are two fundamental changes in how the module will work. First, it will be dependent upon views and rely solely on views to provide its blocks. This is ideal for obvious reasons and it all but makes the idea of providing a separate block completely pointless. The module will provide a default view with a custom node ID argument that performs the FULLTEXT query. It will also have a sort handler and an extra field for displaying the score as determined by thr FULLTEXT search as a raw decimal or a percentage. All of these Views features are currently working and will be released soon.

The second fundamental change, which is still in development, is support for including CCK fields in the FULLTEXT searches. It won't be dependent upon CCK, but will certainly try to take full advantage of it. So, where I'm at now is integrating the searches into the views query. This is somewhat complex because of the nature of indexing in FULLTEXT queries. A lot of parts have to go into ensuring that the indexing is most efficient while users on the front end add and remove CCK fields.

This issue is now considered fixed with the release of Similar entries 2.0 which has views integration.

However, I like the idea of adding filters for title, body, or any other field (since fields are now supported, as well). Will be making a separate issue for that and I think that certainly can be implemented. It will likely be a single filter in which you can select fields to filter th search by.

Closing this issue so it more accurately reflects it's completion on the project page. For additional feature requests for the new views integration please open another issue.