CCK fields with automatic database storage have no way to identify which node they originate from when output by a view. The universal views handler for content fields calls content_format() as:

content_format($field, $item, $field_data['options']);

So when any field module's hook_formatter() is called, no node information is passed to that function. Here's a one-line patch which passes the pseudo node object $data to content_format, so hook_formatter will be able to discern which node the field data originates in.

Index: content_views.inc
===================================================================
RCS file: /cvs/drupal-contrib/contributions/modules/cck/content_views.inc,v
retrieving revision 1.2
diff -u -r1.2 content_views.inc
--- content_views.inc	24 Oct 2006 12:16:16 -0000	1.2
+++ content_views.inc	6 Dec 2006 03:34:31 -0000
@@ -101,7 +101,7 @@
     $view_column_name = 'node_data_'. $field['field_name'] .'_'. $attributes['column'];
     $item[$column] = $data->$view_column_name;
   }
-  return content_format($field, $item, $field_data['options']);
+  return content_format($field, $item, $field_data['options'], $data);
 }
 
 /**

The $data object is not in fact a node object, but it does contain the nid so fields can load the node themselves if necessary. I imagine a node_load for every field in a view might have a performance impact.

Comments

yched’s picture

yched commented

CCK fields with automatic database storage have no way to identify which
node they originate from when output by a view
CCK fields have no way to identify which node they originate from. In Views or in 'regular' node view.

This is currently by design - what's your use case for this ?

karens’s picture

karens commented

I think this is a good idea, and I have had situations where this would have been helpful. The data already exists, so we are not doing any extra work. I don't have time to actually text the patch right now, but it looks like it would work.

karens’s picture

karens commented

Sorry yched! Looks like we cross-posted. The $data item is a Views object which has already been generated and it always contains the $nid, and the content_format function already is expecting an optional $node object, so this seems like a reasonable thing to do and costs nothing. Fields that don't need that info can ignore it. Do you see any problem with doing this? I may be missing something.

yched’s picture

yched commented

content_format function already is expecting an optional $node object
Yes, I overlooked this. If so, then it's OK and my "so-so" comment does not hold :-)

quicksketch’s picture

quicksketch
he/him
commented

Great (preemptive) thanks for putting this in!

@yched A use case for me is linking to full node page from a field. Imagefield automatically creates several different options for viewing each size available in imagecache. It would be useful to be able to provide the option in Views for thumbnails to link to the original node in which they are contained, but this currently would be very difficult without any node information available to the field.

yched’s picture

yched commented
Component: content.module » Views Integration
yched’s picture

yched commented

http://drupal.org/node/102357 has been marked a duplicate of this (different consequence of $data not being passed to the formatter)

RayZ’s picture

RayZ commented
Status: Needs review » Reviewed & tested by the community

I confirm that this fixes http://drupal.org/node/102357 (i.e. this is a bug fix, not just a feature), so, unless someone thinks otherwise, I think it's RTBC.

yched’s picture

yched commented
Status: Reviewed & tested by the community » Fixed

committed - thanks quicksketch
(er I just notice I forgot the credit in the cvs log...)

quicksketch’s picture

quicksketch
he/him
commented

Thanks!

Anonymous’s picture

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