How to use Drupal image styles with a civicrm custom field (type file)

[cfusch]

I need to use a Drupal 'Image Style' on a CiviCRM custom field in a Drupal View 'Rewrite Results'.  Is there a way to use Drupal image styles with CiviCRM created images??

I created a CiviCRM custom field in events.  The field is of type, 'file', and the file is an image.  I've created a drupal view of the event information and the image along with it ... no problem, but need to use drupal image style with it.

(the image style I need to use is extended by Breakpoints and Picture) 

Carl

[Coleman Watts]

I'm pretty sure drupal imagecache simply works off of "magic" directory names. So if you rewrite the url to be sites/all/files/imagecache/my_preset/civicrm/image_name.jpg instead of  sites/all/files/civicrm/image_name.jpg it should "just work" (assuming you get the directory path exactly right - check how other image files are working to verify this).

[petednz]

i was just looking at a way to stop large civi images loading the whole file size when I only need a thumbnail

I am probably misunderstanding the magic involved and/or we may not have things set up correctly as i am testing on sites that have been upgraded or converted - or we do caching some other way and that stops drupal default image caching ... (wildly guessing)

but in pure drupal land we have images at

https://civicrm.org/sites/civicrm.org/files/styles/case-study/public/MCUA_Blue_Gray_Horizontal_Logo_mono.png?itok=RxikPFt_

and changing the path to another 'image style' does the expected

https://civicrm.org/sites/civicrm.org/files/styles/medium/public/MCUA_Blue_Gray_Horizontal_Logo_mono.png?itok=RxikPFt_

i can't seem to get anything by adding imagecache to the path anywhere

(i know imagecache went in to drupal core in D7 so may be something i need to check up on)


------

reading http://drupal.stackexchange.com/a/59199/13882 seems to endorse what you are saying but it is on a d6 question

[cfusch]

Hi, Pete!

I haven't tried it yet, but will do so this evening.  But just for clarification, I create sized images using "image styles' under drupal admin > configuration > media > image styles.  I create a style that fits my size requirements and sometimes crops the file.  Then when pulling an image into a view, there is an image formatter drop-down that includes the usual thumbnail, small, medium, and large .... AND includes any image styles that have been created.  The result is getting any size image that is uploaded to be formatted based on the selected ~image formatter / image style.

The good thing about this is when used in conjunction with the modules, Breakpoints and Picture,  the images are dynamically resized based on media queries and furthermore, the *file* size is reduced by the Picture module making for faster uploads to mobile devices.

It would be great if CiviCRM would enable custom fields for images that would either use Drupal's Image Styles and/or something of the same in the CiviCRM core.  This would solve the problem of having to use a URL for an image which requires some acrobatics to display the image. (Pete you probably remember this from an earlier discussion).

Also, your comment about the location is closer to the mark, the Image Styles (and generated breakpoint/picture styles) are located in sites/default/files/styles/  directory. 

I'm going to give this a shot later and see if they actually work ... not sure of how the breakpoint/Picture styles will work, though ... maybe some magic will happen.  :-)

Carl

[petednz]

"It would be great if CiviCRM would enable custom fields for images that would either use Drupal's Image Styles"

I concur. Question will be who has time/resources to implement this. We 'can' do it, but don't have a client who would resource it, and it wouldn't be high up on our list of things we can improve in drupal/civi in our own time to be honest.

[sonicthoughts]

Just a quick note that I've been struggling with managing custom image fields in civicrm too.  The requirement is to have at least one image per event.  There are lot's of events.  Adding a native civicrm image file "works" but has several "problems"

1. The imagefile handler in civicrm (ie. imagefile?id=95&eid=894) relies on a very inefficient http call for each image.
2. Does not seem to have any caching
3. Can't find any documentation oh how imagefile works (but can sort of figure it out....)
4. User has to upload an image from desktop - can't use finder, reuse images, etc.
5. There are some issues (bugs?) with user filing handling (ie. remove/replace)
6. If an image is missing, the system hangs for a while and consumes resources and then fails with no error.

The advantage is that it is a nice integrated workflow when creating events.
I created a view with images using the Drupal CivicrmEntity module.  The challenge is that the views handler sees the image as text, so no drupal file / entity goodies (like image styles, caching,etc.)  The solution I went with is https://www.drupal.org/project/imagecache_external which let's you use an external image.  It seems to work ok on the drupal side, but still having problems with native civicrm file handler.  Another approach is to create a rule that copies the image to drupal.  Started down that path but the file entity module does not support entity updates via rules (yet.)  Coding is always a solution but I get squeamish when there is code to maintain ..

[Chris Burgess]

This actually came up on the CiviCRM website recently - both the partner logos at the bottom of the front page and the contributor headshots along the top take up about half the front page load time. (Scroll down to requests 84 onwards for the imagefile requests.)

So here's what I suggested in email on the same topic - and yes ImageCache External was the "simple" solution. Looks like we arrived at the same conclusions sonicthoughts! To do that you'll just need to get the URL out of your View and then pump it into ImageCache External as a source. If providing the image path from CiviCRM Entity is the solution you need, let's make it happen.

Getting CiviCRM Views to co-operate with ImageCache would be a good improvement and a performance boost to use cases like this, but there are probably easier solutions than fixing it in CiviCRM.

Simplest solution probably to use Drupal’s ImageCache External module to retrieve the images from CiviCRM, thus wrapping ImageCache around them. CiviCRM remains the original source but is not hit except when creating the original image.

Alternatively, moving images away from CiviCRM to Drupal file fields with public storage would permit those files to be accessible directly as well, but that’s probably more work to migrate across. Might need to look into that if ImageCache External doesn’t fix it.

ImageCache actions / processors are nice extras, but the main thing here I think is that serving images via CiviCRM probably has a performance penalty - instead of your webserver just reading the file off disk / from cache, CiviCRM is getting initialised many times and each of those involves a CMS bootstrap, CiviCRM bootstrap, lots of DB activity and then reading the image and spitting it out via PHP ... and along the way, losing the nice headers your webserver probably serves on most static files to encourage caching the file on the network (which ImageCache-processed images will get).

IMO using ImageCache kinda counts as "copying the image to Drupal" since you're essentially copying it to a file cache when you point at the image via ImageCache. IDK how well ImageCache External handles caching but it's probably better than the status quo (none).

Probably aim to serve images from CiviCRM to logged-in staff only, and prefer serving from ImageCache when it's for public viewing if possible.

[Chris Burgess]

Figured I've give this a shot - here are my notes on doing so. Turns out this is not a new trick: Drupal #1276730 - Webform CiviCRM Integration: Contact Image

@sonicthoughts, I don't think we actually need CiviCRM Entity to achieve this? CiviCRM Views will let you extract image URLs for contact images and custom fields.

For custom fields with files, CiviCRM protects files in the customFileUploadDir per default (because these are contact data), so work is required to make them accessible to your webserver (but not to the general public, unless you actually want that).

Also, for custom fields, CiviCRM Views supplies the value of Custom Fields as the file_id and renders it as a URL later, while for Contact Images it supplies the full URL. This can be handled by re-using the code from civicrm_handler_field_custom_file::render() as a function in Views PHP's "Setup Code" option when rendering the custom field. Guessing you wouldn't need to do that at all if doing this in the theme layer instead.

Views PHP isn't required if you use the theme layer to output the imagecache external theme() functions. I'd stay away from Views PHP myself on live (that's what themeing is for), but this way I can export the view and share it easily in a gist. Here you go, hope it helps: https://gist.github.com/xurizaemon/4a4e80273f89f0c570d2

[sonicthoughts]

Thanks!  For some reason with the latest update of views, imagecache_external is wreaking havoc on the server.  seems to make a recursive call somewhere.  I'm inclined to copy the image to drupal so it can be managed using drupal Media, etc.  Found a nifty rules module - https://www.drupal.org/project/rules_download which grabs a URL (stream wrapper), creates a file and optionally adds to the db.  There are lot's of approaches, but as a system builder, I always get into trouble when trying to manage code (yeah, I know, better to manage my own code than someone elses ..) 

Will post how things turn out...

[Chris Burgess]

I noticed in the ImageCache External module settings there's actually an option to copy the image to Drupal as a managed file, which might save you some of the work - you'd just need to make the association back to the contact somehow when the managed file is stored perhaps.

Performance-wise, because that's the big boost here - for single requests comparing CiviCRM's image file handler versus ImageCache External, I saw huge differences with this - I think if you're serving images from CiviCRM, there's a pretty big performance improvement to be had here.

I wrote up my results from a small sample test here: https://gist.github.com/xurizaemon/795696d1e8b25b8b9130

[sonicthoughts]

Wow - nice job with the testing and documenting!

I whitelisted my own server with imagecache external and something triggered the a recursive loop.  In the end, I opted for creating some rules using the rules download module that grab the event image and just let drupal handle it. 

I used entity reference and created a content type which can manage the image with a reference to the event.  Most of the Drupal integration experience seems to be around contacts, but we have lot's of events with images that give event listings impact.  The goal was to simplify event creation workflow and keep everything in civicrm via custom fields.  We use several custom fields to make things happen in event listings like taxonomy, publish to facebook, show on home page slider, etc.

In retrospect, with the ease of the event reference via entity reference and views, I would just have everything live in drupal and provide a link (or use a rule/hook) on the event creation backend to edit "additional event info" field and use civicrm_entity to access the native event data.  Custom fields are not fully supported in civicrm_entity and drupal has so many goodies to manage media, it just makes sense to keep it there.  If I were doing it again, I'd just keep all custom event fields in drupal.

For contacts it may be different. Civicrm has really nice reporting, searching, etc. for contact custom data but for events, I don't see much downside to managing custom info in drupal.