Views: Add option to display image fields as image

I don't see a problem with letting fields of type "url" and/or fields of entity type "file" have a "use as image source" option, the latter of course also with image styles. Will just have to see when I've got time to do this.

I'd like to second this request, my project isn't going anywhere fast without images in views. I've got them displaying by rewriting the image URLs as:

<img src="[field_showcase_file_url]"/>

seperated by

"/><img src="

... but of course they display full-size, which is less than ideal.

Congratulations on your work with this module, it's seriously awesome. With support for images, it's going to be killer :)

subscribing :)

edit: summary of the body field also cannot be used in a view.

edit: summary of the body field also cannot be used in a view.

This does work (or it should), but will only display the summary that was set. If none was set (implying that a trimmed version of the full text should be used), this won't display anything.
I agree that this isn't optimal, though. Please create a new issue in the Entity API issue queue for this (summary property not being set to the default when empty).

Hi drunkenmonkey,

will do, and you are right I did not set a summary.

regards

Any update about this? Thank you =)

No, sorry. I'm pretty busy at the moment and have to struggle even to keep up with bug reports and support requests (even though Shadlington does a pretty good job of answering those before I get to them ;)), so can only get a few new features in now and then.
But this shouldn't be too difficult, so it is going to get done, even if it might still take a month or two.

I'll try and look at this; this week.

cool thnx

Update on what I have found so far.

When creating normal database views a user has a completely different set of fields to choose from which contain option forms to select things like the image field's style.

Search API Views implemented it's own field handlers which don't currently support things like image field styles. If we just added these options It would be duplicate code and initially only support the specific options we targeted.

View's implementation of fields from the Fields API is very flexible for its needs by using the Field API to discover what option forms should be present - so we could be better off extending what Views has already done.

I think Search API Views was originally forced to implement its own field handlers because Views handlers didn't have a distinction between how a field was renders and where the value comes from. This issue is now dealt with in views 3.x-dev #975400: Refactor field render() functions to accept $value, allowing reuse

All the field handlers provided by Views are geared towards accessing field values from the database. So then comes into play the Entity API which Search API already depends on as its focuses on using Entity Objects as the data source rather than the database.

Shalington's link #1077148: add an entity-view row plugin is a start on a patch for the Entity API to provide a new row style for Views which can display an entity in any available build modes such as Full View or Teaser. This is good because potentially the Search API will return the full Entity objects from the search index so that Drupal doesn't need to do the heavy work of loading entity objects from the database.

So I am currently thinking that we could do more work on the Entity API patch to also make an Entity API Fields row style available which would provide all the field handlers which we are used to in Views by extending View's Field API implementation for Option Forms and Rendering but loading the values from the Entity object instead of the database.

Of-course that's far easier said then done! I'll continue to look at the issue and let you know how i get on.

Yes, your analysis is pretty accurate. Extending the Views handlers directly and feeding them search result data is the eventual plan, and would fix a lot of related issues. I just haven't looked into this very much, yet, so try to just fix the little issues that pop up. Sadly haven't time to solve the underlying issue properly.

So, if you had time to look into this, and at least discover what could be done and how, this would be a huge help and get us closer to solving these issues once and for all.

If you need someone to test I am in, not much of a coder unfortunately.

subscribing

Hi there - firstly, thanks for the excellent module. Secondly, are there any progress updates for this issue?

It's still on my radar but I'm a very occupied on a new job so if anyone else can chip please do. A number of the patches mentioned above have moved forward now.

I am going to up this to major, there is no support for images basically. Not being able to display images, seems to be quite an missing option.

As far as I know, doing an HTML rewrite already works? So there's at least a work-around.
I decide more based on the number of subscribers (apart from perceived urgency) of an issue, so this one will be tackled next time I have some spare time anyways.

I've been looking at this on and off for awhile and came to the conclusion that Views needs a lot more decoupling from SQL so handlers can be reused.

I've got 2 sandboxes to look at this here:
Views http://drupal.org/sandbox/JoeMcGuire/1220856
Search API http://drupal.org/sandbox/JoeMcGuire/1220888

Both sandboxes have branches which you can use to move a view from a SQL query backend to a Search API query keeping the existing Row Style, Field Formatters and Sort Criteria. It's very much a proof of concept so far and lots of work will be needed on the API. I'll try and put together some more documentation and a demo shortly but for now feel free to have a nose around those branches and post any issues.

@drunken Often, support for core features such as image - when not provided could be classified as major, hence me doing so.

@ Joe: Wow, that must have been quite some work! I'm completely with you regarding Views' unnecessary focus on SQL backends.
Have you already create a Views issue? That might be interesting for them, too. Although I doubt this will make it into 3.0, maybe this will finally really improve in the 4.x branch …
Note also that #1172970: provide a unified way to retrieve result entities might considerably improve this (and maybe also solve the issue here).

@ Bojhan: Due to the mentioned SQL-affinity of Views, there are tons of Views filters, arguments, field handlers, etc., which the Search API currently doesn't support. We can't create major issues for all of them.

So is this possible now?

So is this possible now?

With an HTML rewrite, yes, I think so. By just clicking a checkbox, no, not yet.

subscribe

sub

subscribe :)

Following #1266036: Add generic Views entity tables with fields and relationships instead might be better – that, and Search API's related #1231512: Use real Relationships instead of level magic in Views integration, should solve this issue, too.

I also found the suggestion in http://drupal.org/comment/reply/1109318/4459084#comment-4459084 as a great workaround for this in simple situations. Also gives the opportunity to use styles/colorbox etc etc.

Subscribe.
The entity view is a great workaround but it can't work in a specific case with Commerce module. It is when you want each of your product variations to have their own result. In that case you need to display a line for each product of the product display.

See #1266036-14: Add generic Views entity tables with fields and relationships and #1231512-16: Use real Relationships instead of level magic in Views integration for two patches that would solve this issue (by using the field formatter for all Field API fields).

(Gonna put this one to "closed (duplicate)" once these are commited.)

subcribe

@monkey... great effort thnx!

As said, see #1231512: Use real Relationships instead of level magic in Views integration.

For anyone trying to display entity reference or taxonomy related images with a style... e.g. "field_taxonomy_reference > field_taxonomy_image".

It seems that search api views still does not render second level images. The workaround has been #2. Allowing you to overwrite with html to display the raw image.

With this solution you can display your images with a style. You will need "views_php" with "#153" patch to fix the modules $row variables issue.

1. Index "field_taxonomy_reference > field_taxonomy_image: File name".

2. Add the field to your view, display hidden, rewrite the field output to "public://your_image_file_structure/[field_taxonomy_reference_field_taxonomy_image_file_name]

3. Add "global php field" and insert your version into output code:

<?php
$img_url = $row->field_taxonomy_reference_field_taxonomy_image_file_name;
$style = 'your_image_style_machine_name';
?>
<img src="<?php print image_style_url($style, $img_url) ?>”>

4.Your view preview should now be showing images properly. Alternatively, change "public" to "private" in step 2 if you're using the private filer system.

Note, you need to use public:// rather than the base url of your site for this function to work.

The great thing is that if the image hasn't yet been created then Drupal does it automatically!

Is this actually a duplicate? It's the only issue I can see specifically addressing images.

This is great provided you have only 1 image, or if your image field is multi-value, that views provides the Multiple Values option - however it's not working for Referenced Entity image fields.
I could get the Referenced Entity Field to work if it was not also a Multi-Value field using the method discussed here #2263017 Image field formatters in Referenced Entity images in Search API Views?

However if your image field is a Multi-Value field as mine is, then without the Multiple values option or the ability to filter on delta=0, then the image fails to render because the URL field contains all URLs in a comma separated string.
This discussion was thought to be a solution however the issue persists for referenced entity image fields #1331342 'Multiple field settings' in a Serach API index view does not function correctly for image fields