Active
Project:
Imagefield Crop
Version:
7.x-2.x-dev
Component:
Miscellaneous
Priority:
Critical
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
2 Jul 2012 at 05:45 UTC
Updated:
28 Apr 2017 at 02:55 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
fraweg commentedComment #2
fraweg commentedNo Ideas?
It is a great problem that all files must be stored public!
Comment #3
fraweg commentedAm I alone with this issue ?
Comment #4
blackice2999 commentedHi,
you are not alone :) - Did you have solved your problem ?
Comment #5
fraweg commentedHi 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
Comment #6
Coyote commentedSorry 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.
Comment #7
nrackleff commentedI 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.
Comment #8
bitcookie commentedOkay,
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.