Hello,

when I use the private file system for Image crop the picture is not displayed. It seem to be the same issue like this:

http://drupal.org/node/423652

Best regards
Frank

CommentFileSizeAuthor
#7 crop-preview.png24.64 KBnrackleff

Comments

fraweg’s picture

Priority: Major » Critical
fraweg’s picture

No Ideas?

It is a great problem that all files must be stored public!

fraweg’s picture

Am I alone with this issue ?

blackice2999’s picture

Hi,

you are not alone :) - Did you have solved your problem ?

fraweg’s picture

Hi Blackice2999,

not really...I used this for the the user pictures...for the default pictures in drupal there is a solution:

http://drupal.org/node/1438940

But for this module there is no activitation in that.. :-(

Best regards
Frank

Coyote’s picture

Issue summary: View changes

Sorry to necro-post, but we're still seeing the problem where image-crop doesn't work properly when using the private file system. What we're seeing is that the initial crop works, but if you go back and edit the node, the original image file is missing, because it apparently attempts to save to a directory under system/files, which doesn't (and probably shouldn't) exist.

nrackleff’s picture

StatusFileSize
new24.64 KB

I am seeing exactly the same behavior as Coyote in comment #6 as well when using private files. Initial crop works, but going back to edit shows broken images. See attached. And, this is a problem in the 7.x-1.x-dev version as well.

bitcookie’s picture

Okay,

I traced this, and the issue stems from file_get_file_references() being unable to find entities related to the crop preview. This is because the crop preview is not actually stored as a value in the field's table in the database.

Since hacking core isn't an option, I think imagefield_crop should implement hook_file_download on its own and correct for this case.

Here's an initial attempt at this. I used image_file_download as the basis for the check. Unfortunately this adds a small SELECT query onto every file download operation, so maybe there's a better way. The hook will search for the corresponding "regular image" as the basis for allowing access to the thumbnail, then return the thumbnails headers if allowed.

Just drop the following in the .module file and it should resolve the bug.

/**
 * Implements hook_file_download().
 *
 * Control the access to private imagefield crop thumbnails
 */
function imagefield_crop_file_download($uri) {
  $files = file_load_multiple(array(), array('uri' => $uri));
  if (count($files)) {
    $file = reset($files);
    if ($file->status) {
      
      //Grab associated master image
      $large_image = db_query("
        SELECT id FROM {file_usage}
        WHERE {file_usage}.fid = :fid
        AND {file_usage}.module = 'imagefield_crop'
      ", array(':fid' => $file->fid))->fetchObject();
    
      //If associated master is found, use that for file_file_download check
      if(!empty($large_image)){
        $large_image = file_load($large_image->id);
        $large_image_access = file_file_download($large_image->uri, 'image');
        if(!empty($large_image_access) && is_array($large_image_access)){
          return file_get_content_headers($file);
        }
      }
            
    }
  }
}