CRM-16479 Support image styles for contact image in Drupal Views

    Details

    • Documentation Required?:
      None
    • Sprint:
      4.7.11 Drupal
    • Funding Source:
      Contributed Code

      Description

      CRM-16009 fixed an issue with the contact image field not working correctly in Views.

      However, the contact image field still only works when the 'original' image is used. The image URL breaks if you set a different image style, using: Set image style options > Image style.

      This results in broken URLs, eg:
      https://styles/150px_square/https/[site]/civicrm/contact/imagefile?photo=[image]_1ba8ae4df0da4b77de36de6164bf8a2b.png&itok=eSeYqpie

        Attachments

          Issue Links

            Activity

            [CRM-16479] Support image styles for contact image in Drupal Views
            David Greenberg added a comment -

            This is the sort of issue that would be great for someone from the community to either send in a PR or submit to the paid issue queue: https://civicrm.org/paid-issue-queue

            shawn holt added a comment -

            If someone takes this on, please include ALL images, not just for contact types if someone takes this on. It seems once images get resolved for contacts, custom image fields for events always lags behind

            John K. added a comment - - edited

            I started looking in to this but I ran into a problem trying to get the custom image upload 'URL'. The code currently gets the custom upload directory from the config object, but we need it formatted as a relative URL in order to pass it to imagecache. This is further complicated by the fact that windows puts the slashes in the opposite direction, so a fix like this, based on Alex C's work on the other issue, won't work:

            if (!empty($this->options['image_style']))

            { // it is assumed that the civicrm directory for custom file uploads is in /files/ somewhere.. otherwise this will break. $split_customFileUploadDir = explode('/files/',$config->customFileUploadDir); // returns $photo as ?photo=<value> $civicrm_image_string = parse_str(parse_url($img_url, PHP_URL_QUERY)); $file['path'] = "public://" . $split_customFileUploadDir[1] . $photo; }

            If anyone can suggest a reliable way of getting the custom file upload URL (preferably relative to the files directory), rather than the directory, that would pretty much solve the issue...

            David Greenberg added a comment -

            John - if you don't get a reply this week, check back w/ Coleman on IRC next week (he's back from leave then).

            Coleman Watts added a comment -

            John K. maybe catch me on irc about this... I'm not sure what you mean by a URL relative to the files directory... did you mean file path instead of url?
            The windows slashes are a pain but I've found the best thing is to just str_replace them away, as php on windows will work fine if you give it forward slashes in a file path.

            Link Swanson added a comment -

            In 4.6.6 the Views contact image field generates an invalid image src URI when you choose a Drupal image style preset. The invalid src looks like this:

            http://styles/medium/http/YOURSITE/civicrm/contact/imagefile?photo=image.jpg&itok=QVe_ZydE

            Seems that the parts of the URL are all mixed up.

            John K. added a comment -

            I've updated this issue since the option to configure an image style was removed completely in 4.7.0: CRM-17638

            This was great for simplifying the handler, and removing unnecessary integration code. It also provides a fresher base to tackle this issue as a feature request.

            John K. added a comment - - edited

            I've submitted a proof of concept for supporting image styles.

            It also adds some further improvements, hiding certain elements from the options form if they are not relevant. Though these should probably go into a separate PR....

            The thing I'm still struggling with is getting the path to Civi's files directory relevant to the site's root. There's a terrible cludge in place at the moment to figure out what the path should be. We wouldn't want this in place for when the changes are merged in, obviously. However, finding the correct path might be blocked at the moment by: CRM-18144 ?

            This is the bit we need to fix up:

                  $config = CRM_Core_Config::singleton();
                  $split_customFileUploadDir = explode('files', $config->customFileUploadDir);
                  $image['path'] = str_replace('\\', '/', substr($split_customFileUploadDir[1], 1)) . substr(strstr($value, 'photo='), 6);
            shawn holt added a comment -

            BTW - there is a similar issue for civicrm entity and may make sense to collaborate on this: https://www.drupal.org/node/2351509#comment-10983479

            Coleman Watts added a comment -

            The fix for that cludge would be to use Civi::paths()

            John K. added a comment - - edited

            I was looking at Civi::paths() but that seems to return paths with [civicrm.files], or not the path relative to the document root. Perhaps I missed the right method to use...

            I'll take another look, thanks for the pointer!

            John K. added a comment -

            The problem is that we need to find the path to the image file relative to the drupal public files directory, so that the image style can be generated correctly, ie with:

            http://localhost/civi/sites/default/files/styles/thumbnail/public/civicrm/custom/mugshot.jpg
            

            The bit we need to get out is:

            civicrm/custom/
            

            The methods in Civi::paths() can return the full path to the CiviCRM file upload directory, or the format "[civicrm.files]/custom". Neither or which are sufficient.

            So this solution compares the Drupal public file path to Civi's to get the relative path...

                  $wrapper = file_stream_wrapper_get_instance_by_uri('public://');
                  $drupal_upload_path = $wrapper->getDirectoryPath();
                  $civi_upload_path = Civi::paths()->getUrl(Civi::settings()->get('customFileUploadDir'));
                  $split_customFileUploadDir = explode($drupal_upload_path, $civi_upload_path);
                  $image_path = substr($split_customFileUploadDir[1], 1) . substr(strstr($value, 'photo='), 6);
                  $image['path'] = str_replace('\\', '/', $image_path);
            

            But this doesn't feel like much less of a cludge than before... At least nothing is hardcoded apart from the public scheme and it uses the new methods...

            John K. added a comment -

            Along with the above we could check that the CiviCRM files directory is 'compatible' with image styles before displaying the option on the views form.

            This adds a bit more complexity to the handler, but is probably the tidiest solution from the user perspective. Coleman Watts what are your thoughts on this?

            John K. added a comment -

            Coleman, I hope you don't mind me assigning this to you to take a look at when you get the chance. Let me know how'd you like me to finish this one off.

            Coleman Watts added a comment -

            I don't have any better ideas, but Tim Otten is more familiar with the Civi:paths code than I am.

            John K. added a comment -

            I'll rework this is the proposal in my previous comments then, and get it in a mergable state for QA

            John K. added a comment -

            OK ready for QA - has this missed the 4.7.8 run?

            shawn holt added a comment -

            BTW - Think it would be difficult to backport to 4.6.x?

            John K. added a comment -

            I don't think the Civi::paths() stuff is in 4.7, so it would be a case of swapping that out - more like the state of it in this commit:
            https://github.com/civicrm/civicrm-drupal/pull/364/commits/c668ca69f3099d5a8587e537120446055426a5cd

            But that loses a lot of the dynamic working out.

            Nevertheless, shouldn't be too hard to do if someone wants to take it on.

            John K. added a comment -

            PR received a positive review from Nicolas Ganivet on GitHub =]

              People

              • Assignee:
                Unassigned
                Reporter:
                John K.

                Dates

                • Created:
                  Updated:
                  Resolved: