Views 2 Support in 6.x

+1

joachim, i'd be into splitting them into two modules but the only problem with that is that you'd really want to share a taxonomy between them... any ideas?

IceCreamYou, not the most useful comment.

Yeah... I was going for motivation, not usefulness. I'm not capable of actually helping with this except for testing.

I'm confused about views support in 6.x ... in the image handbook page on creating galleries, it says views has default image gallery views ( http://drupal.org/node/207216 and I posted the same question there ) but I think that documentation / handbook page is talking about image 5.x-2.x .... ?

i vote to incorporate views into image 6.x ...any idea if this is happening as of yet

Marked #259067: Add Views 2 support as duplicate.

Re #5: Yes, that's about version 5.x as it says in the top right of the book page.

marked #268048: Views compatibility as a duplicate

committed the attached to HEAD. it moves the views code into .inc files.

as for how the views2 code itself should work i've got no idea. but at least now the patches will be on the right files.

@drewish, I'm currently using the Image and Views module and have this compatibility issue. Could I ask how long will it be before the functions in image.views.inc and image_attach.views.inc get converted according to Views 2's API?

Here's a patch to the views inc file that gets you an image field for the views 2.0 module. It is very basic and only has the one field, but it's a start!

ugh yeah I'm having more difficulty also, the views aren't coming out right. I'm on Alpha 5 of views 2.0, that might be a problem for me too. I'll upgrade tonight and test it some more.

couldn't get the options to work, simplified it down, now just need to figure out why it prints that "image:" part before the image.

I'm on windows too, and don't think this is even "patch" quality so here is the contents of my .inc file:

---

<?php
// $Id: image.views.inc,v 1.1 2008/06/16 18:06:01 drewish Exp $

function image_views_data() {
	// Basic table information.

	// Define the base group of this table. Fields that don't
	// have a group defined will go into this field by default.
	$data['image']['table']['group']  = t('Image nodes');
	
	// For other base tables, explain how we join
	$data['image']['table']['join'] = array(
	'node' => array(
	  'left_field' => 'nid',
	  'field' => 'nid',
	  'extra' => array(
		array('field' => 'content_type', 'value' => 'image', 'numeric' => FALSE),
	  ),
	),
	);
	
	$data['image']['nid'] = array(
		'title' => t('Image'), // The item it appears as on the UI,
		'help' => t('The image to display.'), // The help that appears on the UI,
		'field' => array(
		  'handler' => 'image_views_handler_image_image',
		  'click sortable' => TRUE,
		 ),
		 'filter' => array(
		   'handler' => 'views_handler_filter_numeric',
		   'label' => t('Value'),
		   ),
		'sort' => array(
		  'handler' => 'views_handler_sort',
		),
	);

	return $data;
}

/**
 * Views handler for displaying the image in a link to the the image node
 */
function image_views_handler_image_img_link($fieldinfo, $fielddata, $value, $data) {
  $node = node_load($data->nid);
  return l(image_display($node, $fielddata['options']), "node/{$node->nid}", array('html' => TRUE));
}

/**
 * Views - Generate a list of all the valid sizes that are available
 */
function image_views_handler_filter_image_size($op) {
  foreach (_image_get_sizes() as $key => $size) {
    $a[$key] = $size['label'];
  }
  return $a;
}

class image_views_handler_image_image extends views_handler_field_numeric {

  function ensure_my_table() {
    if (!isset($this->table_alias)) {
	  $alias = $this->table;

      if (empty($alias)) {
        $alias = NULL;
      }

      $join = new views_join();
      $join->construct($this->table, 'node', 'nid', 'nid', $join_extra);

      $this->table_alias = $this->query->add_table($this->table, $this->relationship, $join, $alias);
    }
    return $this->table_alias;
  }

  function render($values) {
	$node = node_load($values->nid);
	return image_display($node);
  }

}

since this is totally broken in the current version, i'll have a pretty low threshold for committing. feel free to mark it rtbc when you two feel it's ready.

Here is a new version, basically I'm using the Image Size field in the database as the field for the view. Then I've included two views:

* a default view that shows "My Photos", it uses the Image Size field for rendering and for filtering.
* a default view that shows images by username like http://yourdomain/images/admin

The duplicates are fixed with this also, next steps will just be more rendering options aside from the image size.

If anybody else can help test it out, it should be ready for commit.

<?php
// $Id: image.views.inc,v 1.1 2008/06/16 18:06:01 drewish Exp $

function image_views_data() {
	// Basic table information.

	// Define the base group of this table. Fields that don't
	// have a group defined will go into this field by default.
	$data['image']['table']['group']  = t('Image nodes');
	
	// For other base tables, explain how we join
	$data['image']['table']['join'] = array(
	'node' => array(
	  'left_field' => 'nid',
	  'field' => 'nid',
	  'type' => 'INNER',
	),
	);
		
	$data['image']['image_size'] = array(
		'title' => t('Image Size'), // The item it appears as on the UI,
		'help' => t('Specify as a field to render the image node, specify as a filter to limit which image is shown.'), // The help that appears on the UI,
		'field' => array(
		  'handler' => 'image_views_handler_field_image_size',
		  'click sortable' => TRUE,
		 ),
		 'filter' => array(
		   'handler' => 'views_handler_filter_string',
		   'label' => t('Value'),
		   ),
		'sort' => array(
		  'handler' => 'views_handler_sort',
		),
	);

	return $data;
}

/**
 * Views handler for displaying the image in a link to the the image node
 */
function image_views_handler_image_img_link($fieldinfo, $fielddata, $value, $data) {
  $node = node_load($data->nid);
  return l(image_display($node, $fielddata['options']), "node/{$node->nid}", array('html' => TRUE));
}

/**
 * Views - Generate a list of all the valid sizes that are available
 */
function image_views_handler_filter_image_size($op) {
  foreach (_image_get_sizes() as $key => $size) {
    $a[$key] = $size['label'];
  }
  return $a;
}

class image_views_handler_field_image_size extends views_handler_field {
	function render($values) {
		$node = node_load($values->nid);
		return l(image_display($node, $values->image_image_size), 'node/'. $node->nid, array('html' => TRUE));
	}
}

/**
 * Implementation of hook_default_view_views().
 */
function image_views_default_views() {

	$view = new view;
	$view->name = 'my_images';
	$view->description = '';
	$view->tag = '';
	$view->view_php = '';
	$view->base_table = 'node';
	$view->is_cacheable = '0';
	$view->api_version = 2;
	$view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */
	$handler = $view->new_display('default', 'Defaults', 'default');
	$handler->override_option('fields', array(
	  'image_size' => array(
		'label' => '',
		'exclude' => 0,
		'id' => 'image_size',
		'table' => 'image',
		'field' => 'image_size',
		'relationship' => 'none',
	  ),
	));
	$handler->override_option('filters', array(
	  'uid_current' => array(
		'operator' => '=',
		'value' => 1,
		'group' => '0',
		'exposed' => FALSE,
		'expose' => array(
		  'operator' => FALSE,
		  'label' => '',
		),
		'id' => 'uid_current',
		'table' => 'users',
		'field' => 'uid_current',
		'relationship' => 'none',
	  ),
	  'image_size' => array(
		'operator' => '=',
		'value' => 'thumbnail',
		'group' => '0',
		'exposed' => FALSE,
		'expose' => array(
		  'operator' => FALSE,
		  'label' => '',
		),
		'case' => 1,
		'id' => 'image_size',
		'table' => 'image',
		'field' => 'image_size',
		'relationship' => 'none',
	  ),
	));
	$handler->override_option('access', array(
	  'type' => 'none',
	  'role' => array(),
	  'perm' => '',
	));
	$handler->override_option('style_plugin', 'grid');
	$handler = $view->new_display('page', 'Page', 'page');
	$handler->override_option('path', 'my_images');
	$handler->override_option('menu', array(
	  'type' => 'none',
	  'title' => '',
	  'weight' => 0,
	));
	$handler->override_option('tab_options', array(
	  'type' => 'none',
	  'title' => '',
	  'weight' => 0,
	));


	$views[$view->name] = $view;
	
	
	$view_by_username = _image_view_by_username();
	$views[$view_by_username->name] = $view_by_username;
	

	return $views;
}

function _image_view_by_username() {
	$view = new view;
	$view->name = 'user_images';
	$view->description = '';
	$view->tag = '';
	$view->view_php = '';
	$view->base_table = 'node';
	$view->is_cacheable = '0';
	$view->api_version = 2;
	$view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */
	$handler = $view->new_display('default', 'Defaults', 'default');
	$handler->override_option('fields', array(
	  'image_size' => array(
		'label' => '',
		'exclude' => 0,
		'id' => 'image_size',
		'table' => 'image',
		'field' => 'image_size',
		'relationship' => 'none',
	  ),
	));
	$handler->override_option('arguments', array(
	  'name' => array(
		'default_action' => 'not found',
		'style_plugin' => 'default_summary',
		'style_options' => array(),
		'wildcard' => 'all',
		'wildcard_substitution' => 'All',
		'title' => '',
		'default_argument_type' => 'user',
		'default_argument' => '',
		'validate_type' => 'none',
		'validate_fail' => 'not found',
		'glossary' => 0,
		'limit' => '0',
		'case' => 'none',
		'path_case' => 'none',
		'transform_dash' => 0,
		'id' => 'name',
		'table' => 'users',
		'field' => 'name',
		'relationship' => 'none',
		'default_argument_user' => 0,
		'default_argument_fixed' => '',
		'default_argument_php' => '',
		'validate_argument_node_type' => array(
		  'blog' => 0,
		  'image' => 0,
		  'page' => 0,
		  'story' => 0,
		),
		'validate_argument_node_access' => 0,
		'validate_argument_nid_type' => 'nid',
		'validate_argument_vocabulary' => array(),
		'validate_argument_type' => 'tid',
		'validate_argument_php' => '',
	  ),
	));
	$handler->override_option('filters', array(
	  'image_size' => array(
		'operator' => '=',
		'value' => 'thumbnail',
		'group' => '0',
		'exposed' => FALSE,
		'expose' => array(
		  'operator' => FALSE,
		  'label' => '',
		),
		'case' => 1,
		'id' => 'image_size',
		'table' => 'image',
		'field' => 'image_size',
		'relationship' => 'none',
	  ),
	));
	$handler->override_option('access', array(
	  'type' => 'none',
	  'role' => array(),
	  'perm' => '',
	));
	$handler->override_option('style_plugin', 'grid');
	$handler = $view->new_display('page', 'Page', 'page');
	$handler->override_option('path', 'images/%');
	$handler->override_option('menu', array(
	  'type' => 'none',
	  'title' => '',
	  'weight' => 0,
	));
	$handler->override_option('tab_options', array(
	  'type' => 'none',
	  'title' => '',
	  'weight' => 0,
	));
	
	return $view;
}

here's that as a patch. i'm not so sure about the new default view... joachim what are your thoughts?

I totally agree about the options. I just couldn't get them to work correctly.

So let me see if this is correct from what you're saying, make a single default view that is a node view that shows one image per row, with a set of options for which image size to show.

I left drupal 5.x a long time ago and don't remember the field names, I can change that to whatever like in the drop down how should it read?

It reads: "Image nodes: Image Size" right now I think.

I will be working more on it next week.

Image attach views integration: http://drupal.org/node/279844

marked #282577: No Views Implementation? as a duplicate

I've applied this patch, and the good news is that it works reasonably well! A bit of feedback:

• If the current method of a field + filter is required, then there needs to be a bit of help in the UI pointing that out. As well, the operator for the filter needs to note that you type in the name of the derivative you want to display. It should probably be a select with possible derivatives instead.
• A better solution like mentioned would be to have the options in the field options itself. I'll look into it and see what I can find. If that's not possible, how about dynamically creating fields with one field linking to a kind of derivative?
• I'm using the lightbox2 module to display full-size images. If I add a Node Title field, it takes me to the node when you click on the text (versus the image). I haven't determined where the issue is (I assume it's lightbox), but if there is something which helps lightbox out with normal node views then we should be sure that it's included in view fields as well.
• The default view my-images doesn't seem to work out of the box, taking me to a 404.

Thanks,
--Andrew

Marked #306867: No Image: Display Image as a duplicate.

Any update?

yes?

may the patches posted here be applied on the new version of views?

I patched the latest dev version of none of the views options or default views show up. Cleared cache too. Any ideas of what I may be missing?

Thanks!
shrop

i can confirm this.

i once had it working with the patches in this topic
is there a lot of work to be done to make image.module fully support views in drupal 6?

Hi there,

after trying every possible patch and instruction provided in this forum I've had no luck with getting the image module to work with views 2. Could someone give me some pointers as to what steps/patches I need to get this to work. I'm currently using drupal 6.4 on linux.

Any pointer is much appreciated!

marked http://drupal.org/node/309899 as duplicate.
marked http://drupal.org/node/279844 as duplicate.

I'm having this issue too because of the recent change in Views API at RC2 stage.

However, I have a stable setup with the current Image module (03 Sept), and Views2 RC1.

It's frustrating though I need to update Views to fix another problem, but that breaks all my images!!

subscribing

same situation as sampeckham: stable setup with Image 6.x-1.x-dev and Views 6.x-2.0-rc1 but updating to Views2 RC2, RC3 and RC4 breaks image attach field.

subscribing

marked http://drupal.org/node/318238 as duplicate.

Just curious if this is still actively being looked in to?

I'm about to start in on a site and this is my one stumbling block.

I followed the instructions by KarenS at http://angrydonuts.com/attention-views-api-developers and was able to get the Image module working with the latest version of Views (6.x-2.0-rc5) quite easily.

Sorry I don't know how to make a patch for this.

First add the following to image_attach.module

function image_attach_views_api() {
return array(
  'api' => 2,
  'path' => drupal_get_path('module', 'image_attach'),
);
}


function image_attach_views_handlers() {
  return array(
  'info' => array(
    'path' => drupal_get_path('module', 'image_attach'),
    ),
  'handlers' => array(
    'image_attach_views_handler_field_iid' => array(
     'parent' => 'views_handler_field',
     ),
    ),
  );
}

and then move the image_attach_views_handler_field_iid class to its own file image_attach_views_handler_field_iid.inc.

This worked for me straight away! Great stuff. Now if they would just update the Image module formally!

This Views api is causing me problems across the board.....

sampeckham, it'd get updated much quicker if there was a patch ;)

http://drupal.org/patch

May be a stupid questions, but it's my problem right now...

After putting the code into image_attach.module i have to:

"and then move the image_attach_views_handler_field_iid class to its own file image_attach_views_handler_field_iid.inc."

What code do i have to put into image_attach_views_handler_field_iid.inc?
and
Where can i place image_attach_views_handler_field_iid.inc?

Thx

The image_attach_views_handler_field_iid class is in the image_attach.views.inc file. Move this class to image_attach_views_handler_field_iid.inc in the same directory.

Hello.

I cannot get this to work correctly.

I can select "Image attach: Attached image Attached image " as a field in Views right now, but no Image will be shown.

Here is what I have done:

Added this to image_attach.module at the very end:

/**
* Own Adding
*/

function image_attach_views_api() {
return array(
  'api' => 2,
  'path' => drupal_get_path('module', 'image_attach'),
);
}


function image_attach_views_handlers() {
  return array(
  'info' => array(
    'path' => drupal_get_path('module', 'image_attach'),
    ),
  'handlers' => array(
    'image_attach_views_handler_field_iid' => array(
     'parent' => 'views_handler_field',
     ),
    ),
  );
}

Cut this out of image_attach.views.inc and added it into a new file named "image_attach_views_handler_field_iid.inc (and added the <?php at the beginning of the new file). So the new File looks like this:

<?php

/**
 * Render an Image Attach field with options to control the size of the image
 * and the style of the link.
 */
class image_attach_views_handler_field_iid extends views_handler_field {
  function option_definition() {
    $options = parent::option_definition();

    $options['size'] = array('default' => IMAGE_THUMBNAIL);
    $options['as_link'] = array('default' => 'none');

    return $options;
  }

  function options_form(&$form, &$form_state) {
    parent::options_form($form, $form_state);

    $sizes = image_get_sizes();
    $options = array();
    foreach($sizes as $name => $data) {
      $options[$name] = $data['label'] . '('. $data['width'] . 'x' . $data['height'] . ')';
    }
    $form['size'] = array(
      '#type' => 'select',
      '#title' => t('Image Size'),
      '#options' => $options,
      '#default_value' => $this->options['size'],
    );

    $form['as_link'] = array(
      '#type' => 'select',
      '#title' => t('Link'),
      '#options' => array('none' => t('No link'), 'node' => t('Node'), 'image' => t('Image Node')),
      '#default_value' => $this->options['as_link'],
    );
  }

  function render($values) {
    $image_node = node_load($values->image_attach_iid);

    if (!$image_node && node_access('view', $image_node)) {
      return '';
    }

    switch($this->options['as_link']) {
      case 'node':
        return l(image_display($image_node, $this->options['size']), 'node/' . $values->nid, array('html' => true));
      case 'image':
        return l(image_display($image_node, $this->options['size']), 'node/' . $image_node->nid, array('html' => true));
      default:
        return image_display($image_node, $this->options['size']);
    }
  }
}

This is how image_attach.views.inc looks like now:

<?php
// $Id: image_attach.views.inc,v 1.2 2008/08/28 09:51:03 drewish Exp $
/**
 * Implementation of hook_views_data().
 */
function image_attach_views_data() {
  // Basic table information.
  $data = array();

  // Define the base group of this table. Fields that don't
  // have a group defined will go into this field by default.
  $data['image_attach']['table']['group']  = t('Image attach');

  // For other base tables, explain how we join
  // LEFT is the default, but let's be explicit
  $data['image_attach']['table']['join'] = array(
    'node' => array(
      'left_field' => 'nid',
      'field' => 'nid',
      'type' => 'LEFT',
    ),
  );

  // changed field
  $data['image_attach']['iid'] = array(
    'title' => t('Attached image'), // The item it appears as on the UI,
    'field' => array(
      'handler' => 'image_attach_views_handler_field_iid',
      'click sortable' => TRUE,
    ),
    'help' => t('An image attached to a node.'),
  );

  return $data;
}

This is the Views SQL Code:

SELECT node.nid AS nid,
   image_attach.iid AS image_attach_iid,
   RAND() AS _random
 FROM fsrlapb_node node 
 LEFT JOIN fsrlapb_image_attach image_attach ON node.nid = image_attach.nid
 WHERE node.type in ('image')
   ORDER BY _random ASC

Can anyone please point me to the right direction? Thanks in advance.

@JTHAN: It will be hard for people to help you if you post code like that.

It is much more polite to post a patch - then people will be able to see easily what you have changed.

See http://drupal.org/patch for help.

Right, I've read through this thread, and it seems to have switched contexts part of the way through.

It was wrongly marked as a duplicate of Image attach views integration: http://drupal.org/node/279844

That patch needs updating for the new Views API, as described above in #45, so I have created a patch and attached it that node for testing.

However, it would be great to expose the rest of the module to views too, which is what the initial patches in this node tried to accomplish. I'll dig into that and the Views documentation to see if I am up to updating these patches for the updated views 2 API.

I say this is probably critical.

Attached is a patch to (begin to) add Views 2 support to Image module.

Disclaimers:
--this is my first contributed patch ever of all time so be nice.
--i don't use CVS for version control so i hope i rolled the patch in a way that's actually usable
--it's been rather minimally tested
--the code probably deviates from Drupal standards in many many ways

What it does:
--adds the Views 2 API hook to image.module
--moves views.inc to a new /views directory and basically rewrites it for the new api
--creates three new class files for custom field and filter handlers
--the patch was diffed against the latest dev

Known issue:
--If the view attaches the image node to a base node via a CCK Noderef relationship, attempting to sort on any of the files table fields (filesize, filepath) throws an error.

Patch on #55: This works beautifully with Views 6.x-2.1 on Drupal 6.6. I couldn't salvage my original views of my images, but at least I could re-create them and they worked!!

Many, many thanks.

krlucas, the big things that jumps out at me is that there a bunch of whitespace problems with your code that sort of make it hard to review. drupal's coding standards (which the image module tries to follow) specify that spaces are to be used for indenting rather than tabs.

Patch on #55: i tested it, the patching went ok, but the /views directory wasn't automatically created.
i did it manually and moved all view related files.

it doesn't do what i want it to do though, i find no way of only seeing the thumbnails.. but maybe i'm overlooking something.. will try to learn from your codeEDIT: and so i did, you can just add a filter.

this works for me thanks a lot!

I get an error when I try to patch the image.module file. Cygwin says: Hunk #1 FAILED at 1032. The other files get patched fine. I put the image_views_api function manuelly in the image.module file but I still can't see any Image Fields in Views.

it works now! I just had to put the image_views_api function at the very bottom of image.module

great work krlucas! the only thing that misses for me now is a field for an image with an link to thickbox. Do you have any ideas how to do that?

@schlotterich
its just a setting in thickbox i think, i did the same yesterday, but reverted it because it wasn't working the way i wanted it too.
i did a lot yesterday so sorry, dont remember how exactly. if you really have trouble figuring it out send me a message and i'll try re-enable it on my site.

I'll look into cleaning up the code (white space, comments etc) on patch #55 so it can actually be reviewed and maybe committed. For my current project I have the views integration for Image and Image_Attach running as standalone custom modules so as to avoid any conflicts with other Image updates. Thus, there's some search and replace work for me to turn them into real patches.

Cleaned coding-style and formatting. Reworked comments, and added plenty of @todos. The patch does the ground-work so far, but the actual implementation looks and feels wrong. The different fields should be just one field with an additional field configuration form to adjust the link, image size, aso.

i'm wondering if we could use relations for the various image sizes.

Applied and Tested. Comments:

• (Previously mentioned) Link functionality should be provided as an option indeed, much like the node title field.
• I have 3 different image size; By Default, for every image node, I got 3 rows until I added the Image Size filter. While I like the filter because it allows me to expose that to the user, I don't think it's correct by definition that for a single image node 3 rows are returned.
• Do we need Image Node ID? I believe that would be the same as Node ID.

Proposed extra features:

• I think the integration needs one field for terms: Term image. I think image_gallery currently chooses the most recently added image. It would also be lovely if this default behavior is adjustable somehow as per the field options.
• Image size as an Argument. Can't think of an immediate use case, but it seems like a reasonable thing to have.

New patch; Summary of modifications/additions:

• Re-factored image size to become an option for the Image field (but the filter is still kept, reason below).
• Re-factored Image Link to become an option for the Image field.
• Added new field handler for image_size to print the label of the size instead of the internal name.
• Removed the {files} integration in favor of new relationship, it was suggested in the code as a // Todo to use the Upload: Attached files relationship but that didn't work as it seem to be only integrating files which have been uploaded by upload.module. A new similar relationship was introduced which works.
• Replaced node_load() by a lighter alternative (hopefully not too light) as suggested in one of the // Todos
• Added new argument and argument validator for image size.
• Removed Image: Image Node ID field since that's the same as Node: Nid
• Removed Image: FileID field, already provided by {files}
• Several random tweaks (removed click sortable from filters, removed repeated group as it's inherited by default, field handlers renamed for consistency, fetching from $values in render() is more reliable but not tested with CCK nodereference)

TODO/Doubts:

• I didn't remove Image Size filter. Thought it could be useful to expose to end user.
• Which default views should we provide? Though I guess this is something that should wait until we are done with the integration so we know what fields/filters/arguments/etc we have.
• I wasn't sure what Image Base Link is, so I left it; I just had it extend Image class itself for less redundancy. But it's still a separate field while it looks like this should be added as an option as well.
• Should we integrate with Terms (Like provide a Term: Image which would get an image and display it next to the term. like image_gallery.module)?

Image base link was supposed to provide a link to the base node of the view in the case where the Image node was included secondarily via a relationship (CCK noderef for instance). For instance, imagine the base node is content type "Product" and you include the Image node via relationship. Image Base node would render an HTML image tag wrapped in an anchor tag with an href to the *Product* node, not the *Image* node. So that's that. Solved a problem for me but might be better left to the theme layer.

Anyway, I will definitely test the patch and report back. All your changes look superb.

-kl

Thanks for clearing up the nodereference bit! Here is a new patch with mainly 2 new things:

• Works with CCK Nodereference and other relationships.
• Re-factored Image: Image linked to base node into an option for Image: Image.

Another iteration, nothing major this time. Just minor fixes and comments. Also re-factored image field handler's render() into smaller build units to allow other modules which work with image module to extend from this handler and override the bits they would like to extend.

ever heard people calling you hero? anyway. does *3.path work with Image 6.x-1.0-alpha3 ?

doh another fan.. Yes, everyone calls me by that actually :P

Seriously though, it works with alpha3 indeed. :)

The patch in #69 applies cleanly to alpha3 and provides image:image and image:image size fields, and image:image size filter, as advertised. I was able to set up a nice view with a grid of scaled images very easily.

The only problem I had is with image links. Whether I choose "link the image to..." base node or image node, the path is set to "/node/" (see below). Linking the node title works correctly. The only problem is with the link to the image.

<div class="views-field-image-html">
<span class="field-content"><a href="/node/"><img src= "http://www.example.com/sites/default/images/picture.thumbnail.jpg" alt="some title" title="some title"  class="image image-thumbnail " width="200" height="194" /></a></span>
</div>

The problem is in the $url assignment in image_url() (image/views/image_views_handler_field_image.inc). $image_node should be $image_nid and $base_node should be $base_nid.

  function image_url($values) {
   $image_nid = $values->{$this->aliases['image_nid']};
   $base_nid = $values->nid;

    $url = '';
    if ($this->options['which_node'] == 'image_node') {
      $url = 'node/'. $image_node;  
//      should be  $url = 'node/'. $image_nid; 
    }
    else if ($this->options['which_node'] == 'base_node') {
      $url = 'node/'. $base_node;
//    should be  $url = 'node/'. $base_nid;
    }

    return $url;
  }

This fixes the problem.

Also I am curious if the class name is correct with the extra space at the end?

Coder didn't report any problems aside from small code formatting issues (Actually more problems in the original alpha3 module than in theses new views extension files).

I'll test further and report back if I see any problems. But right now, this looks excellent. Thanks!

Good catch, must be after I refactored this bit into smaller functions for extensibility. I will get another patch on, maybe with image_attach support as well.

Also, I have an important fix for a rather important issue with the way image_size is currently being added to the query is not correct. As it should be part of the join not as a WHERE. The reason is that if you are would like to get nodes with images AND others without imaging, Views2 will build the query with a LEFT JOIN. However, the WHERE clause for image_size will mean that only nodes whose images match the e.g. image_size='thumbnail' are returned. Thus, only nodes with images will be returned (which is not what the user wants). Solution? the image_size condition should be part of the join with the image table not a WHERE.

So far I've been working against alpha3, if it's not too much trouble you could try with that.

As we speak, I'm working on image_attach (for some reason I can't get it right, yet) but once I'm done I will try to generate a patch against HEAD as well :)

This patch really helped me out. I haven't done any extensive testing, but so far so good.

I'm looking forward to the next patch. Also this should be applied to HEAD soon, as this greatly improves the usability of the image module.

subscribe

yeah, alienbrain and i have been in contact about this. i'm on vacation and didn't want to commit it before i left. he was going to clean some things up and have something for me to test later this week.

I'm very excited to see this code, thanks so much. This is one of those things where you get 90+% done with your project, and then you suddenly realize there's actually no way to fit the pieces of the puzzle together. Oops!

marked http://drupal.org/node/332687 as duplicate.

Here is the same patch as #69 with the addition of another join to the files table so you have access to the fields in the file table for the given images you are pulling.

With this patch you can access filepath, mimetype, size, etc... (All the fields in the files table)

All that was added to patch from #69 is the following code in image_views_data():

$data['files']['table']['join']['node'] = array(
    'left_table' => 'image',
    'left_field' => 'fid',
    'field' => 'fid',
  );

I've invested more hours recently in that patch but it appears that there is a fundamental decision that needs to be taken regarding on the approach we will take.

After raising my doubts with Earl and a bit of discussion, here is how I see the problem now:

Background

In order to display an image, we need its path which is stored in the {files} table; We need to join to that table.

Problem

Normally, we will join to the {files} table like this: ... {image} LEFT JOIN {files} USING (fid) .... But now what happens when you also add a field from the upload module. Upload module needs to add the {files} table as well which would be like: ... {upload} LEFT JOIN {files} USING (fid) ... . Now clearly both JOINS shouldn't exist in a single query. unless they are distinguished as relationships. Views cannot make an automatic decision as to which table (image or upload, or any other table doing the same) it should be using for joining the {files} table.

Solution

There are 2 solutions, or rather approaches. Unfortunately neither is perfect.

Approach 1

We leave the choice to the user; We do that by not joining to {files} ourselves, and relying on the user to add a relationship to the files. The relationship will include an option to choose the image size(s).
Pros:

1. The more correct, technically.
2. Makes all features from {files} base available as well (i.e. all files data like file size, mime and so on).

Cons:

1. Not obvious for end users unless special attention can be given to instructing user to do this.

Approach 2

We create a new alias of {files}, or we execute a separate query in pre_render() to get all filepaths from {files} for all images involved (Example: views_handler_field_upload_fid::pre_render) and then we don't need to join {$files} in the main query. The former is what is being done in recent patches.

Pros:

1. Easy and straight forward to the end user (totally transparent).

Cons:

1. Our new aliased table won't automatically have the Views integration of {files}. We will need to duplicate the fields of {files} in our new aliased {files}. Or;
2. If we execute a separate SQL query to get the needed data from {files} pre rendering; The user won't be able to access the files data and will have to add a relationship to {files} to get the files data and then we will end up with 2 joins of {files} which could end the user up with duplicate rows.

How to proceed?

What do y'all think? Feedback appreciated! :)

Meanwhile, I will see if I can provide 2 patches with the different approaches!

Regarding #81:
Actually tom, while this works for Images, it breaks {files} for everything else. Actually, I think it's a demonstration of the Problem explained in #82.

The definition you added tells Views that {files} is always linked through {image}. And while that suits our own needs. It breaks upload module, for instance. Try this:

• Create a node (e.g. page) and attach a file to it using upload module.
• Create a views listing of pages and add the field "File: Name".
• Nothing will be displayed. Look at the query in the preview, you will notice that Views is joining with the {image} on the page nodes. Which is obviously not what you want in this case.
• That's why this sort of decision (i.e. How should the view link to {files}) should ideally be made through a relationship. Because then when you add "File: Name" field, the field will have an option to choose which relationship to use; In which case you can choose either Upload or Image relationship.

Re: #82, The Image Module is still in Alpha mode. I am wondering if there anything could be done by the module maintainer to solve the problem (as well as integrate this patch)? Your Approach 1 cons says "Not obvious ..."; think about if a user has to apply your patch in order to use Views with image, it's already not obvious enough.

I like approach 1 of #82. We are already used to creating relationships with other modules, so approach 1 seems more natural and just as obvious for people that are already familiar with creating views.

Many modules already require adding relationship. I don't think it's much of a drawback. Putting it in the instructions, as having a sampel view with the relationship is probably enough.

Interesting, can you guys point me to some modules which require adding a relationship?

Meanwhile, I'm almost done with a patch which requires a relationship, and I was planning to continue working to add a twist which allows it to fallback to the pre_render() approach (an approach already used by upload.module, check it for details; but basically, it executes a separate SELECT ... {files} ... IN (fid1, fid2, ...etc) to get the filepaths with one separate query) ONLY if it cannot find the relationship present.

Flag and Voting API comes to mind, though I'm sure there are others.

New patch; It requires the "Image: Files" relationship to be added.

As usual, summary of changes:

• Fixed links for image nodes as reported in #72
• Relationship now has an option "Image Size" to choose which image size to get.
• Refactored how image field was getting its image's filepath with {files}. Now relies on the new Image: Files relationship. A notice is added when the relationship isn't present.

Hint: Apply patch with patch -p0 < image_views2_integration4.patch while in image module directory.

committed part of this so i could drop the old views1 support... here's a re-roll.

Just curious, is the patch in #90 different than that of #89, or is it a successor?

I applied #89 and tried to get my views working with the image. Whenever I set up the relationship, the table would vanish; it couldn't render. Then, after a few minutes, the AJAX queries in Views crashed my database server! I'm not kidding. I went through the process twice from scratch, and each time I ended up having to reboot my (production) server!!!

Very strange. I have trouble believing this patch could be causing it, but see no other logical explanation. Weird. So be careful with this patch! I'm rolling back to the standard Views for my Drupal 6.6 setup, but will keep an eye out for future patches and give them a try.

When I applied the patch, I got this sql error :

    * user warning: Unknown column 'filepath' in 'field list' query: SELECT COUNT(*) FROM (SELECT DISTINCT(node.nid) AS nid, node_revisions.teaser AS node_revisions_teaser, node_revisions.format AS node_revisions_format, node.title AS node_title, node.created AS node_created, image.nid AS image_nid, image.image_size AS image_image_size, filepath, node.sticky AS node_sticky FROM node node LEFT JOIN term_node term_node ON node.vid = term_node.vid LEFT JOIN term_data term_data ON term_node.tid = term_data.tid LEFT JOIN node_revisions node_revisions ON node.vid = node_revisions.vid LEFT JOIN image image ON node.nid = image.nid WHERE term_data.vid in ('1') ORDER BY node_sticky DESC, node_created DESC ) count_alias in D:\xampp\htdocs\Mosaic\sites\default\modules\views\includes\view.inc on line 697.
    * user warning: Unknown column 'filepath' in 'field list' query: SELECT DISTINCT(node.nid) AS nid, node_revisions.teaser AS node_revisions_teaser, node_revisions.format AS node_revisions_format, node.title AS node_title, node.created AS node_created, image.nid AS image_nid, image.image_size AS image_image_size, filepath, node.sticky AS node_sticky FROM node node LEFT JOIN term_node term_node ON node.vid = term_node.vid LEFT JOIN term_data term_data ON term_node.tid = term_data.tid LEFT JOIN node_revisions node_revisions ON node.vid = node_revisions.vid LEFT JOIN image image ON node.nid = image.nid WHERE term_data.vid in ('1') ORDER BY node_sticky DESC, node_created DESC LIMIT 0, 10 in D:\xampp\htdocs\Mosaic\sites\default\modules\views\includes\view.inc on line 723.

Anyone has any idea about this ?

Sorry, I forgot to add Image Files relationship :(
Seem like drupal is very hard to use, and quite tricky too

Thanks to the #50 reply. I follow this and get image_attach work correctly.

I don't know how to create a patch because i'm using windows & svn. So I attach the final result. Maybe someone help me to create a patch

Well, welcome to Drupal first! :)

Requiring the relationship is indeed not the best thing.. right. But so far we cannot find a nice way around it. It's natural from a technical point of view, but yes, not the best for end users.

This is still an open issue anyway, you are welcome to participate and help make this better if you know Views2 ;)

This patch introduces validation for the existence of the relationship when saving or previewing the view and throws a friendly error if it cannot find it instructing the user to add it.

It requires this patch to views: http://drupal.org/node/343047

@rayray It would be great if you could write reproduce steps. So we could try going through the same steps and see if we can hit this. It would also be useful if you mention the versions of image and views modules you are using.

@alienbrain - thanks. Well, I tried the latest patch of yours, along with the Views one you reference. The integration5 patch seems to have issues with the directory referencing, so I was force to do parts by hand. I do think I did it correctly, however.

So I did get the Image reference to show up in the views I'm working on. The problem happened again: once I added a relationship from the view to the Image (thumbnail size), I saw the MySQL 5 process spike at 100%, and the preview (via AJAX) was trying to render but never did. I waited to see what would happen, but after a bit deleted the relationship and after about 10 seconds the database calmed down. Weird.

I'm running Acquia Drupal 6.6 on this server (1.03) with Views 6.x-2.1 and Image 6.x-1.0-alpha3. The server is running PHP 5.2.4-2ubuntu5.3 and MySQL 5.0.51a. It should also be noted that when I'm looking at the Content Type I'm working on, the image feature I'm looking for is under the Image Attach settings section. I say this to be sure I'm even barking up the right tree!

I'll give it one more shot here before rolling back. Thanks for all your work on these patches, I really appreciate it!

Edit: I did give it another shot, no luck. I updated my Image module to the latest dev version, which did give me this ability, but performance is simply awful! I'm not sure if there's just too many tables involved, or if I have too many issues, or if I need to address some indexing issues, or what. But it certainly appears that my problems with this might just be that we have lots and lots of legacy images on our site, and our database server just can't handle the load.

New patch that introduces Image: Node relationship. This makes it possible to build image views starting from "files". I.e. View type "File" instead of "Node".

@rayray Been using git recently and not yet used to its diff parameters. Always forget to use the right ones. The recent patch shouldn't have that problem.

Now to the main problem, I actually cannot reproduce it yet. I need more information about the View itself. Would it be possible to export your view and attach it?

just to confirm... all I would really like to do is create a view of just the images in a gallery... thats all... Idealy I would like to make the galery type something like a Content type that holds nodes of images. My thoughtis that I would like tto create a slide show based on attached images... I already have that working in my own newbie way... but it seems to work.

so, is there no way to get a list of all image node images?

• Apply the latest patch (at #100).
• Create a new view of Node type.
• Add a filter of node type and select "Image" content type.
• Add a new relationship: "Image: Files". Choose the image size you want.
• Add a new field: "Image: Image".

For galleries, galleries are really just Taxonomy Terms. So if you want a listing of all items in a given gallery. You do the above steps, plus: Add a new filter: "Taxonomy: Term" and select the "Image Galleries" vocabulary then select the term (gallery) you want to restrict results to.

alienbrain, the latest image module dev supports Views2. Have you tried it yet? however, that version doesn't work well with relationship(noderefenence)

Oh oh. Not really. I checked image dev from CVS and by downloading the -dev version from the project page, but didn't find an implementation of hook_views_data() in neither. Only implementation was for hook_views_api().

Perhaps I need help with CVS! :)

alienbrain, you're not rolling patches against HEAD so you're patches aren't applying. you probably need to CVS up your local copy.

it'd be good if when you posted an updated patch you explained what you changed so that i could compare your patch to the last patch i'd applied and make sure it's not missing any changes.

joachim, i don't think it's unreasonable at all. go look at the date module. that's got some wacky setup but that's just what you've got to do to provide the full views capabilities. we need to provide a default view so people know how it works but i don't think we should take away the flexibility from people who might need it.

Impossible to use "cvs diff" command to re-roll patch in #100 because it can't deal with the creation of new files.

Here is a re-roll of the patch in #100 (also using "git diff") against today's CVS HEAD checkout.

It is virtually identical to the original; the only difference being that image.module no longer needs to be patched.

subscribing

pillarsdotnet, that's incorrect CVS can deal with missing files, it cannot create missing directories how ever which is why i committed part of the patch and added the views directory. see: http://drupal.org/patch/create and http://wimleers.com/blog/cvs-diff-new-files-fakeadd

@drewish:

I copied the script from http://wimleers.com/blog/cvs-diff-new-files-fakeadd#comment-288 then switched to my sites/all/images directory and typed:

cvs update -d .
fakeadd views/*.inc
cvs diff -upN

The cvs command output the following:

? views
cvs diff: Diffing .
cvs diff: Diffing content_types
cvs diff: Diffing contrib
cvs diff: Diffing contrib/image_attach
cvs diff: Diffing contrib/image_attach/po
cvs diff: Diffing contrib/image_attach/translations
cvs diff: Diffing contrib/image_gallery
cvs diff: Diffing contrib/image_gallery/po
cvs diff: Diffing contrib/image_gallery/tests
cvs diff: Diffing contrib/image_gallery/translations
cvs diff: Diffing contrib/image_im_advanced
cvs diff: Diffing contrib/image_im_advanced/po
cvs diff: Diffing contrib/image_im_advanced/translations
cvs diff: Diffing contrib/image_import
cvs diff: Diffing contrib/image_import/po
cvs diff: Diffing contrib/image_import/tests
cvs diff: Diffing contrib/image_import/translations
cvs diff: Diffing po
cvs diff: Diffing tests
cvs diff: Diffing translations

Still doesn't cope with new files. Any suggestions?

Typing the command "cvs --version" outputs the following:

Concurrent Versions System (CVSNT) 2.5.03 (Scorpio) Build 2382 (client/server)

Copyright (c) 1989-2001 Brian Berliner, david d `zoo' zuhn,
                        Jeff Polk, and other authors
CVSNT version (Nov 21 2006) Copyright (c) 1999-2005 Tony Hoyle and others
see http://www.cvsnt.org

Commercial support and training provided by March Hare Software Ltd.
see http://www.march-hare.com/cvspro

CVSNT may be copied only under the terms of the GNU General Public License v2,
a copy of which can be found with the CVS distribution.

The CVSNT Application API is licensed under the terms of the
GNU Library (or Lesser) General Public License.

Perl Compatible Regular Expression Library (PCRE)
  Copyright (c) 1997-2004 University of Cambridge.
  Licensed under the BSD license.
  See http://www.pcre.org/license.txt

Specify the --help option for further information about CVS

(Edit)

Tried again with regular CVS with the same results. Running "cvs --version" now outputs the following:

Concurrent Versions System (CVS) 1.12.13 (client/server)

Copyright (C) 2005 Free Software Foundation, Inc.

Senior active maintainers include Larry Jones, Derek R. Price,
and Mark D. Baushke.  Please see the AUTHORS and README files from the CVS
distribution kit for a complete list of contributors and copyrights.

CVS may be copied only under the terms of the GNU General Public License,
a copy of which can be found with the CVS distribution kit.

Specify the --help option for further information about CVS

pillars, fakeadd should have some output. Here's what I did to generate the attached patch.

amorton@paycheck:~/Sites/d6/sites/all/modules/image% cvs up -d -A
? b
? contrib/image_attach/tests
cvs update: Updating .
cvs update: Updating content_types
cvs update: Updating contrib
cvs update: Updating contrib/image_attach
cvs update: Updating contrib/image_attach/po
cvs update: Updating contrib/image_attach/translations
cvs update: Updating contrib/image_gallery
cvs update: Updating contrib/image_gallery/po
cvs update: Updating contrib/image_gallery/tests
cvs update: Updating contrib/image_gallery/translations
cvs update: Updating contrib/image_im_advanced
cvs update: Updating contrib/image_im_advanced/po
cvs update: Updating contrib/image_im_advanced/translations
cvs update: Updating contrib/image_import
cvs update: Updating contrib/image_import/po
cvs update: Updating contrib/image_import/tests
cvs update: Updating contrib/image_import/translations
cvs update: Updating po
cvs update: Updating tests
cvs update: Updating translations
cvs update: Updating views
amorton@paycheck:~/Sites/d6/sites/all/modules/image% wget http://drupal.org/files/issues/image_views2_integration7.patch
--2008-12-19 15:55:45--  http://drupal.org/files/issues/image_views2_integration7.patch
Resolving drupal.org... 140.211.166.6
Connecting to drupal.org|140.211.166.6|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 15496 (15K) [text/plain]
Saving to: `image_views2_integration7.patch'

100%[====================================================================================================================================================================================================================================>] 15,496      56.2K/s   in 0.3s    

2008-12-19 15:55:45 (56.2 KB/s) - `image_views2_integration7.patch' saved [15496/15496]

amorton@paycheck:~/Sites/d6/sites/all/modules/image% patch -p1 -i image_views2_integration7.patch 
patching file views/image.views.inc
patching file views/image_views_handler_argument_image_size.inc
patching file views/image_views_handler_field_image.inc
patching file views/image_views_handler_field_image_size.inc
patching file views/image_views_handler_filter_image_size.inc
patching file views/image_views_handler_relationship.inc
patching file views/image_views_plugin_argument_validate_image_size.inc
amorton@paycheck:~/Sites/d6/sites/all/modules/image% fakeadd views/*.inc
/Users/amorton/bin/fakeadd: added "views/image.views.inc"
/Users/amorton/bin/fakeadd: added "views/image_views_handler_argument_image_size.inc"
/Users/amorton/bin/fakeadd: added "views/image_views_handler_field_image.inc"
/Users/amorton/bin/fakeadd: added "views/image_views_handler_field_image_size.inc"
/Users/amorton/bin/fakeadd: added "views/image_views_handler_filter_image_size.inc"
/Users/amorton/bin/fakeadd: added "views/image_views_handler_relationship.inc"
/Users/amorton/bin/fakeadd: added "views/image_views_plugin_argument_validate_image_size.inc"
amorton@paycheck:~/Sites/d6/sites/all/modules/image% cvs diff -upN > ~/image_220295.patch
cvs diff: Diffing .
cvs diff: Diffing content_types
cvs diff: Diffing contrib
cvs diff: Diffing contrib/image_attach
cvs diff: Diffing contrib/image_attach/po
cvs diff: Diffing contrib/image_attach/translations
cvs diff: Diffing contrib/image_gallery
cvs diff: Diffing contrib/image_gallery/po
cvs diff: Diffing contrib/image_gallery/tests
cvs diff: Diffing contrib/image_gallery/translations
cvs diff: Diffing contrib/image_im_advanced
cvs diff: Diffing contrib/image_im_advanced/po
cvs diff: Diffing contrib/image_im_advanced/translations
cvs diff: Diffing contrib/image_import
cvs diff: Diffing contrib/image_import/po
cvs diff: Diffing contrib/image_import/tests
cvs diff: Diffing contrib/image_import/translations
cvs diff: Diffing po
cvs diff: Diffing tests
cvs diff: Diffing translations
cvs diff: Diffing views

here's the patch.

Hmm... Tried the following:

rm -rf image
cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout -r HEAD -d image contributions/modules/image
wget http://drupal.org/files/issues/image_views2_integration7.patch -O - | patch -d image -p1
cd image
fakeadd views/*.inc

fakeadd aborts, complaining that the CVS directory doesn't exist.

Trying again...

rm -rf image
cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout -r HEAD -d image contributions/modules/image
wget http://drupal.org/files/issues/image_views2_integration7.patch -O - | patch -d image -p1
cd image
mkdir views/CVS
fakeadd views/*.inc

fakeadd outputs the following:

/usr/local/bin/fakeadd: added "views/image.views.inc"
/usr/local/bin/fakeadd: added "views/image_views_handler_argument_image_size.inc"
/usr/local/bin/fakeadd: added "views/image_views_handler_field_image.inc"
/usr/local/bin/fakeadd: added "views/image_views_handler_field_image_size.inc"
/usr/local/bin/fakeadd: added "views/image_views_handler_filter_image_size.inc"
/usr/local/bin/fakeadd: added "views/image_views_handler_relationship.inc"
/usr/local/bin/fakeadd: added "views/image_views_plugin_argument_validate_image_size.inc"

Running "cvs diff -upN" outputs the following:

? views
cvs diff: Diffing .
cvs diff: Diffing contrib
cvs diff: Diffing contrib/image_attach
cvs diff: Diffing contrib/image_attach/translations
cvs diff: Diffing contrib/image_gallery
cvs diff: Diffing contrib/image_gallery/tests
cvs diff: Diffing contrib/image_gallery/translations
cvs diff: Diffing contrib/image_im_advanced
cvs diff: Diffing contrib/image_im_advanced/translations
cvs diff: Diffing contrib/image_import
cvs diff: Diffing contrib/image_import/tests
cvs diff: Diffing contrib/image_import/translations
cvs diff: Diffing tests
cvs diff: Diffing translations

Are you pulling from a different CVS branch than I am?

I'm lost.

I think I've followed the directions (repeatedly) to apply the patch but I'm not seeing the Image:Files relationship or the Image:Image field.

1. I applied the patch in #114 and cleared cache
2. Created new view of type Node
3. Added filter on Node Type: Image
4. Didn't see the Image:Files relationship or the Image:Image field
5. I applied the patch located here: http://drupal.org/files/issues/views_handlers_validate4.patch
6. Created new view of type Node
7. Added filter on Node Type: Image
8. Didn't see the Image:Files relationship or the Image:Image field.

What am I missing?

I'm running views 6.x-2.1 and image 6.x-1.0-alpha3 on drupal 6.6

Attached is a copy of the latest dev version of this module with the appropriate views files included....

Hi
Tried to use "image-6.x-1.x-dev-views2.zip" with "views-6.x-2.2". Added "Image: Image" to field. Added filters "Node: Type = Image " and "Node: Published Yes "

Got this message :

user warning: Unknown column 'filepath' in 'field list' query: SELECT node.nid AS nid, image.nid AS image_nid, image.image_size AS image_image_size, node.title AS node_title, filepath FROM node node LEFT JOIN image image ON node.nid = image.nid LIMIT 0, 10 in /home/sphechr4/public_html/sites/all/modules/views/includes/view.inc on line 725.

tried also with ""views-6.x-2.1" but doesn't work

Anything wrong ? Thanks.

same here as #118

got it.
you need to add a relationship for the size image you want.

*subscribing*

*subscribing*

#117 views module worked for me. I deleted my old image dir then uploaded the new one containing views integration. I got the same error message posted above in #118 but it went away after defining a relationship.

looking forward to a release with views integration included.

pp

please, how can i add that relationship for the needed size?

Is there a patch? What maintainers think about this longlasting issue?

Yes, I think it's time to finalize this issue

Attached is a re-roll of the patch from #114 made against HEAD.

i don't like this code but i'm going to do a new alpha release then ahead and commit it as a starting point.

marked #357413: hooking with views2? as a duplicate.

i went ahead and committed this. grab a -dev version if you want to play with it.

dev version gave me an error when trying to use it in views.

user warning: Unknown column 'filepath' in 'field list' query: SELECT node.nid AS nid, node.title AS node_title, image.nid AS image_nid, image.image_size AS image_image_size, filepath FROM node node LEFT JOIN image image ON node.nid = image.nid WHERE (node.status <> 0) AND (node.type in ('image')) LIMIT 0, 10 in /var/www/sitename/sites/all/modules/views/includes/view.inc on line 725.

@robertdjung: Did you create a relationship for you view? See comments #106 & #120 above.

* Add a new relationship: "Image: Files". Choose the image size you want.
* Add a new field: "Image: Image".

Does image_attach support view2 ?

aha, I had everything except the relationship. Thanks noahb. works like a charm.

Works well. Thanks.

I'm getting the following error message:
user warning: Column 'nid' in field list is ambiguous query: SELECT nid, node.title AS node_title,.... etc.

I'm using the field and relations as described above, anyone with a clue?

Could someone compare this thread patched Views support with the out of box support from the latest dev? At least, the latest dev doesn't require relationship

I got the same error before I defined the relationship. Try deleting/redefining the relationship and see if it clears up the glitch.

Hi. If I create a new view, add a 'page' display, and add the 'Image: Image' field, I get

user warning: Unknown column 'filepath' in 'field list' query: SELECT node.nid AS nid, image.nid AS image_nid, image.image_size AS image_image_size, node.title AS node_title, filepath FROM node node LEFT JOIN image image ON node.nid = image.nid LIMIT 0, 10 in /home/content/m/o/o/moorugs07/html/area3/sites/all/modules/views/includes/view.inc on line 725.

the query being

SELECT node.nid AS nid,
image.nid AS image_nid,
image.image_size AS image_image_size,
node.title AS node_title,
filepath
FROM node node
LEFT JOIN image image ON node.nid = image.nid

I'm using the dev snapshot from 2009-Jan-19, and I tried the patch in http://drupal.org/node/360170 without any changes.

Sorry, I hadn't read all comments, adding the relationship fixed it.
Thanks,

Reading the comments does help.

I was playing around with the latest Image dev version and created a view and a relationship as described in the comments above. When I added my Image: Image field, I got this error just below the "Live Preview" text in the Views UI.

user warning: Column 'nid' in field list is ambiguous query: SELECT nid, files_image__image.nid AS files_image__image_nid, files_image__image.image_size AS files_image__image_image_size, title, files_image.filepath AS files_image_filepath FROM node node LEFT JOIN image image ON node.nid = image.nid AND image.image_size = 'thumbnail' LEFT JOIN files files_image ON image.fid = files_image.fid LEFT JOIN image files_image__image ON files_image.fid = files_image__image.fid LIMIT 0, 10 in /../sites/all/modules/views/includes/view.inc on line 731.

Using Views 6.x-2.3.

Edit: Just realized that when editing my Image field in the View, if I choose "Do not use a relationship" the error goes away and the images appear in the preview.

subscribe

Hello,
Thanks for your work.

I have one more question: can anybody tell me how to automagically replace default image gallery view with that one created by views? Please...
I know it must be smoething with path and arguments, but I can't figure it out.

I'm not sure I understand the question. are you asking for a special format of the image? you can look at imagecache for that. also, there are ways to display images in a jquery or lightbox slide show.

Never mind.
I've found the way to make image_gallery look just as I wanted.

could you please explain how you did it ?
I am attempting the same...
Thanks.

Would be interested in knowing how you made the galleries display as you intended.

At some point when using Drupal 5, the images were no longer sorted by node ID (or posted date). I never looked into it, thinking that I could fix it with views...

I have read through this entire thread, but I'm still confused regarding Image module and Views 2 integration and need some clarification.

I am trying to use the image module with views 2, but when I add to the field list, "Image attach: Attached image" (original size, no link) all I get in Live preview is the text "Attached image:" and no image. I've tried several permutations (different sizes, etc.) but no joy.

I would appreciate it if someone could shed some light on that.

Thanks in advance for some help here.

-Videoman

+ Subscribing

I'm also trying to figure this out. My problem is identical to #152 (and I'm assuming to most of the people in this thread). Have the patches in this thread already been applied to the current version (alpha4)?

Drupal 6.10 core
Image 6.x-1.0-alpha4
Views 6.x-2.3

Thanks in advance!

This thread is running old. is it fair to assume that the patch is fixed in Views 6.x-2.3?

If not then the patch, where does it go?

Which Module?
Which file?
after what and before what?
What hets deleted?

I expect to have the same as 154 and 152. What is the answer to that?

There is a dev Views released 3 days after 6.x-2.3... Does that solve anything?

Thanks

Where is CVS Head?
Which Module?
Which file?

FYI

The usermanual for Image Galleries D6.x links to here. Maybe thats why a lot of newbies show up...

http://drupal.org/node/207216

subscribing

checked out the latest CVS and read the patch code. it's unclear to what version the patch #165 relates, as some of the patch strings are already there.
So I'm not ready to test

I've applied the patch to HEAD of image, and it seems to work OK. However, I would strongly suggest that the patch's additions to the Image module be tested using contributions/modules/image/test/image.test, e.g. run a few use cases in there so the code itself is exercised programmatically. Please don't depend solely on user input.

All that said: thank you, Joachim.

Subscribe. (I hate subscribing when I don't have anything to contribute, but ah well).

Nice work, it seems work OK for me (6.x-1.x-dev 2009-Mar-21).
Can you please add Image: Filename to Sort criteria ?
I would be nice.

I am more confused than I used to be.

#174 says "- the current alpha version of Image (6.x-1.0-alpha4) has no views support"

However, I have been using Image (6.x-1.0-alpha4) with Views2.3 support out of box and no relationship needed. The only thing in Image (6.x-1.0-alpha4) not working is the node referenced Image cannot display.

Joachim,

Yes, I am talking about image_attach working out of box for Views2.3. Am I completely off the topic here?

Hi everyone.
I made a simple video showing how to integrate image gallery and views in case someone still has a problem with this.
I'm not a professional video maker so please be forgiving...
You can download it from mediafire: http://www.mediafire.com/file/zdc4yddn0c2/image+views.avi (34629 KB)
Tried to use youtube but image quality was not acceptable.
-- edit --
Forgot to mention: i use latest dev version (2009-Mar-23) without any patch.
I use admin_menu to simplify administration.

Patch from #165 applies to current -dev but with patch -p3 < ...

Suppose much better to load filepath in main query but image_size already stored as option so no need to select it in image_load (except permissions check)

maybe is there possibility to alter main query with files table (default relation) so (#175) and other can sort images by file params

Another issue - option "link to node" is not working because of image_display() which does not handle additional param as URL (link leads to uploaded file)

Queries generated by view:

Query	

SELECT node.nid AS nid,
   node.title AS node_title,
   node.type AS node_type
 FROM node node 
 WHERE node.type in ('image')
   

Other queries	

These queries were run during view rendering:
[0.76 ms] image_load
/* Webmaster : image_load */ SELECT i.image_size, f.filepath FROM image i INNER JOIN files f ON i.fid = f.fid WHERE i.nid = 12
[0.78 ms] image_load
/* Webmaster : image_load */ SELECT i.image_size, f.filepath FROM image i INNER JOIN files f ON i.fid = f.fid WHERE i.nid = 14
[0.74 ms] image_load
/* Webmaster : image_load */ SELECT i.image_size, f.filepath FROM image i INNER JOIN files f ON i.fid = f.fid WHERE i.nid = 15
[0.82 ms] image_load
/* Webmaster : image_load */ SELECT i.image_size, f.filepath FROM image i INNER JOIN files f ON i.fid = f.fid WHERE i.nid = 16
[0.72 ms] image_load
/* Webmaster : image_load */ SELECT i.image_size, f.filepath FROM image i INNER JOIN files f ON i.fid = f.fid WHERE i.nid = 30
[0.75 ms] image_load
/* Webmaster : image_load */ SELECT i.image_size, f.filepath FROM image i INNER JOIN files f ON i.fid = f.fid WHERE i.nid = 32
[0.58 ms] render_textarea
/* Webmaster : render_textarea */ SELECT name FROM filter_formats WHERE format = 1

good information , thank`s.

sdas

Today I take a closer look to code so agree with (#163) there's a possibility that image does't exists :( suppose it's a different issue
Another side is a permissions for image node if some kind of access control used - nodes can be accessed by all users so I see 2 ways

1) Basic view - should check access by node_access() not image_load() which check only access to image sizes
2) custom view (with relation) - developer should add own filters for access

@182 tested cases - just create image-nodes then create node-view (display is fields) with filter on node_type=image and add field image (basic)

Ok. To get this done I reserved myself some time and did the following:

Definition of some common example use-cases:
1) Simple node view containing the latest images from users using the Thumbnail preset.
2) Image file view displaying image filenames along with their (node) descriptions belonging to a certain category using a custom preset.
3) (Node) View that displays all images that are referenced by story nodes based on a nodereference relationship

Current state, observations:
1)
- I have to choose between two fields, Image: Size and Image: Image. "What?!"
- Chose to go with Image: Image. "Link to Image node/Base node" - I don't understand the difference.
- Error message: "Image: Image field requires Image: Files relationship to work. Add this relationship and try again."
- Adding relationship, filter for Node: type, and sort by Node: Created
- Works.

2)
- Adding field File: Name
- Adding relationship to Image: Node
- Adding fields Node: Body (Image Node), Image: Image
- Adding filter Taxonomy: Term (Image Node)
- Error: "user warning: Column 'title' in field list is ambiguous query: SELECT files.fid AS fid, files.filename AS files_filename, node_image__node_revisions.body AS node_image__node_revisions_body, node_image__node_revisions.format AS node_image__node_revisions_format, image.nid AS image_nid, image.image_size AS image_image_size, title, nid, files.filepath AS files_filepath FROM files files LEFT JOIN image image ON files.fid = image.fid AND image.image_size = 'foo' LEFT JOIN node node_image ON image.nid = node_image.nid INNER JOIN term_node node_image__term_node ON node_image.vid = node_image__term_node.vid LEFT JOIN node_revisions node_image__node_revisions ON node_image.vid = node_image__node_revisions.vid WHERE node_image__term_node.tid = 6 LIMIT 0, 10"
- Missed to select relationship for Image: Image
- Countless duplicate view results (the same image over and over again)
- "Reduce duplicates" for term filter: No help.
- Testing "Distinct": No help.
- Now I realize: These are 5 images and I have 5 presets.
- Testing whether Image: Image Size field helps. No luck. On that note: That's a pretty senseless field.
- Fail.

3)
- Adding relationship Content: NoderefField (which is a nodereference field with multiple values btw)
- Adding field Node: Title (NoderefField)
- Adding field Image: Image, relationship Image: Files (NoderefField)
- I get some results, but those are repeating the same, multiple images
- Tried further, no luck.
- Fail.

With this patch:
0) My previous view (the only that worked) still works. :) Deleted.
1)
- Adding field "Image: Image (basic)", choosing size Thumbnail; no confusing "Link to Image/Base node", yay!
- Adding filter Node: Type, sort by Node: Created
- Works.

2)
- Adding field File: Name
- Adding relationship to Image: Node
- Adding field Image: Image (Image node)
- Wow. First time I see at least a bit of the expected output: One row for each preset of a file. Promising.
- Requiring relationship "Image: Node". Still multiple rows, but always the same size. No luck.
- Note that query basically is: "
SELECT files.fid FROM files files
LEFT JOIN image image ON files.fid = image.fid AND image.image_size = 'foo'
INNER JOIN node node_image ON image.nid = node_image.nid
LEFT JOIN image node_image__image ON node_image.nid = node_image__image.nid
" -- either the LEFT JOIN or the second JOIN on image are most likely causing the duplicates.
- Adding filter Image: Image Size (Image node), selecting the desired preset (again).
- Adding filter Taxonomy: Term (Image node), selecting desired term.
- Works! (Albeit a bit clumsy query due to the needless double-join)

3)
- Adding relationship Content: NoderefField, required
- Adding field Node: Title
- Adding field "Image: Image (basic)" (NoderefField), choosing desired image size
- Expected result.
- Works!

Duly noted:
- Patch was created from wrong directory. Pretty hard to test.

So,
BRILLIANT!
This is a tremendous improvement over what we have currently. Given the fact that only my very simple view worked with the old implementation, I dare to say that we should remove the old implementation completely. It's just cruft we need to maintain. Better remove it and try to come up with actually working solutions (in a separate issue).

Now I just need some brainpower to review the actual code.... not sure whether I'll be able to do this tonight...

Now the hard facts ;)

--- contributions/modules/image/views/image.views.inc Base (1.1)
+++ contributions/modules/image/views/image.views.inc Locally Modified (Based On 1.1)
@@ -12,7 +12,8 @@

Please create patches from the respective project root only. Also, diff -up for context, please.

+  // ----------------------------------------------------------------------
+  // Image table, using either {node} or {files} as possible base tables.

No ASCII-art, please ;) The second line is sufficient.

+    'help' => t('The rendered image of an Image node. This field requires a relationship to be added.'),
...
+      'help' => t('The rendered image of an Image node, shown at a chosen size. This field can be added without a relationship.'),

Those descriptions actually gave me a clue about what those fields provide. The other "Image Size" completely failed in that (rather "Preset name").

+  // ----------------------------------------------------------------------
+  // Image nodes, basic version.
+  // We don't actually need a table since all we do is add fields from the {node} table.
+  // We could make this a #global, but adding ourselves onto {node} allows this field to be used
+  // through relationships if needed (for example through a CCK nodereference field).

Comments should wrap at 80 chars. Also, avoid abbreviations like don't. The second sentence might better work as @todo.

+    'group' => t('Image'),    
...
+  

Trailing whitespace. Blank lines should be blank.

+      'title' => t('Image (basic)'),

Let's rip the other implementation and by doing that also the " (basic)" suffix in here.

+/**
+ * @file
+ * Views handler for Image field: basic.
+ * This is a fake field that doesn't do any querying.
+ * Instead it adds the node table fields we need we need to build a fake
+ * node object to send to image.module to load the correct image.
+ */
...
+/**
+ * Field handler to provide an image tag.
+ * Inherit from views_handler_field_node so we get the 'link to node' stuff for free.
+ */
...
+  /**
+   * Constructor to provide additional fields to add.
+   * We add the fields that image module's image loading will need.
+   */
...
+  /**
+   * Extends the field's basic options with more image specific
+   * options.
+   */
...

There should be blank PHPDoc line between the summary and description. The description should wrap at 80 chars, not before or after.

+    $options['image_derivative'] = array('default' => array(IMAGE_PREVIEW));

I believe the default should be IMAGE_THUMBNAIL, no?

+     $image_html = $this->render_html($values);
+
+       // We inherit render_link() from views_handler_field_node,
+       // which takes care of providing a link to the node if requested.
+      return $this->render_link($image_html, $values);

Wrong indentation.

+  function render_html($values) {
+    $derivative = $this->options['image_derivative'];
+
+    $node = $this->build_image_display_node($values);
+
+    // Image module's hook_load implementation will load in files for all derivatives.
+    // Derivatives larger than the original fall back to the original.
+    // Stale derivatives will be regenerated.
+    image_load($node);
+
+    return image_display($node, $derivative);
+  }

Oh? We are doing separate file loads for each row here? Hum... I see where you're coming from now. Let's go with that for now to provide this for the masses and tinker about other approaches (elsewhere).

+   * Image module functions need:
+   *  - title (for formatting)
+   *  - nid

Lists should start at the previous indentation level, so no extra space before - here.

In general, the comments are sometimes a bit lengthy. Do you think you can rephrase them up to the point? That would be great! :)
Two examples from above:

+    // Depend on image_load() for derivative size fallback logic and rebuilding
+    // of stale image files.
...
+   * Required fields for image_load():
+   * - title
+   * - nid

Just fixed the file locations so further people are able to test. :)

Hi everyone,

I need to use views to select nodes with attached images. Is this possible on current dev version ? If not how to archive that ?

Comment#9 on another issue queue seems to suggest that the current 6.x Dev release of image.module is compatible with views2.

Meaning full Image nodes or images uploaded via image.module can be used as a field in Views2.

Is this correct?

I think nquocbao's question from March 31, 2009 - 04:22 is the same as mine.

We can achieve this by a filter that filter node contains / not contains attached images. But I think it's better if we use right join on field ?

Thanks for the tip Joachim.

I have a content type called 'Image' which utilises image.module to let users upload and submit images.

Views2 will pull the full the node image, title, author info, or teaser. It wont display only the image as views field.

This is the main issue.

subscribe

subscribe

THANKS SO MUCH. I have been scratching my head over this for a week now. Works perfectly for me.

@joachim: I'd like to commit this patch. But why did you rename all views include files? Are you in IRC?

I have committed attached patch (which is basically the same as #196, only minor clean-ups).

Since the views include files changed, and those were only available in 1.x-dev, the files are emptied now (so users of 1.x-dev don't deal with wrong files). The old files need to be removed before creating a new release -- I left a reminder in CHANGELOG.txt.

Thanks for putting so much work into this, joachim!

@all: Please test the new development snapshot (available within 12 hours) and report back in separate issues.

Just downloaded from HEAD, and applied the patch.

Not clear on what these errors mean, but the patch seemed to apply, and seems to work :P

File views/image_handler_filter_image_size.inc is not empty after patch, as expected
1 out of 1 hunk FAILED -- saving rejects to file views/image_handler_filter_image_size.inc.rej
The next patch would create the file views/image_handler_relationship_node_image_file.inc,
which already exists!  Assume -R? [n] y

So far, in testing, it seems to work out quite well.

Is there anything in specific I should be testing?

@#205 You get that error because the patch was already applied to HEAD on May 1 and patch wants to know if it should undo the changes in it, so you should not apply it again.

Sub.

This is the best thing since sliced bread.

Thank you for working on this. I've been testing it in my dev site and so far it's fantastic. I can see images in my views fields and everything is working great.

Yes, thanks, joachim did an awesome job.

Closing now to kick this issue out of the open issues list.

Bookmarking, how to use this views support for the best please?
EDIT: I found it out myself, thanks for the great patch!
Greetings, Martijn

Hello, I tried applying the patch from comment #204 to "image-6.x-1.0-alpha4" using the instructions here and here, but it did not work. The error I got was:

can't find file to patch at input line 8
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|Index: views/image.views.inc
|===================================================================
|RCS file: /cvs/drupal-contrib/contributions/modules/image/views/image.views.inc,v
|retrieving revision 1.1
|diff -u -p -r1.1 image.views.inc
|--- views/image.views.inc	13 Jan 2009 10:10:41 -0000	1.1
|+++ views/image.views.inc	1 May 2009 22:19:38 -0000

This is my first patch attempt, but I'm guessing the problem is that the patch is for vsn 1.1, and the .module version is 1.282. If this is true, can someone tell me how to make this thread compatible with the current version of image.module? And if I'm wrong, can someone tell me what's going on?

Thanks for any help!

Jim