I'm having a problem with the 'image' module in drupal 6.2. I can browse the local file system and add a .GIF or .PNG image, but .JPG and .JPEG images don't work. I've traced it back to drupal_get_form() and drupal_process_form(): looks like the .jpg is not making it into form structure, but that isn't being detected. It results in the first argument to the PHP function 'copy' being a directory rather than a file.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | image.module.patch | 774 bytes | Anonymous (not verified) |
Comments
Comment #1
StephaneC commentedHi,
are you really sure it has something to do with the file type? Let me explain more... I am currently tracking a bug that yields to the same behaviour and the problem is linked with the size of the file (#239748: Uploading image, path/filename becomes base path).
Could you try with a JPG file which size is lower than the .GIF or the .PNG file that allow you to succeed?
Stephane
Comment #2
Anonymous (not verified) commentedI've tracked it down to image_gd_resize() in image.gd.inc. [I don't have imagemagik installed]
Here's what's happening in my case:
image.module:_image_build_derivatives() decides it needs to build a thumbnail image
and eventually calls image_scale().
image_scale() calls image_gd_resize() which calls image_gd_open($file, $extension)
image_gd_open() fails for jpg's because (on my installation) imageCreateFromjpeg() does not exist,
whereas imageCreateFrompng and gif do.
so image_gd_open() returns FALSE, causing image_gd_resize() to return FALSE, which sets
$status to FALSE on line 806 of image.module which causes _image_build_derivatives()
to return FALSE, which zaps out $form_state['values']['images'].
I tried changing lines 814 thru 820 of image.module to:
if (!$status) {
drupal_set_message(t('Unable to create scaled %label image', array('%label' => $size['label'])), 'error');
// return FALSE;
unset($images[$key]);
} else {
$images[$key] = $destination;
}
but drupal insists on having a thumbnail, so it complains and puts nasty messages on the screen.
BTW, there is a potential size related issue in image_scale() because it can return false if it detects 'scaling up'. I think the right answer is to create the thumbnail by copying the original.
I don't think that is a problem if we invoke image_scale_and crop() to create the thumbnail, because it doesn't have the 'don't scale up' logic.
do you still want me to try this for different size files?
Comment #3
StephaneC commentedThank you Mike for this. Your problem is definitively different from the one i'm tracking. There is no need to try for different size files.
Stephane
Comment #4
Anonymous (not verified) commentedI traced my problem down to a configuration error/feature [user error?] in building PHP 5.2.5 on my mac. So, as far as I'm concerned this is resolved.
I've also attached a short patch to 'images.module' to keep '_image_build_derivatives()' from blowing away the entire $form_state['images'] array. I think it's a good thing to do because it keeps the upload working even if the thumbnail can't be built.
Comment #5
sunPlease submit a proper patch. See http://drupal.org/patch for details.
Comment #6
sunSorry, without further information this issue can only be closed as not reproducible.
Feel free to re-open this issue if you want to provide further information. Thanks.