Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Using the standard GD2 API it converts the image. When I set the ImageMagick option it comes up with an error of 'unable to convert.....no such file or directory'. Not sure if my settings are correct or this has to do with my hosting server, but under the configurations it is finding the ImageMagick on the server and telling me the version of 6.0.7.
I have also put in a request to Hostmonster, the hosting server to see if it is on their end. Is this on the server or is their something I am missing?
Comments
Comment #1
drewish CreditAttribution: drewish commentedif you enable debugging what do the commands and output look like?
Comment #2
cbassig CreditAttribution: cbassig commentedIt is broken down into two messages.
1. (message status)
* ImageMagick command: /usr/bin/convert -resize 167x125! -crop 167x125+0+0! -quality '75' 'sites/examplesite.com/files/leaf.jpg' 'sites/examplesite.com/files/imagecache/leaf.jpg'
* ImageMagick output:
2. (message Error)
ImageMagick reported an error: convert: unable to open image `sites/examplesite.com/files/leaf.jpg': No such file or directory. convert: missing an image filename `sites/examplesite.com/files/imagecache/leaf.jpg'.
FYI: the site is on a multi site install....the reason for sites/ect....
Comment #3
drewish CreditAttribution: drewish commentedso did you double check that there's actually a file named sites/examplesite.com/files/leaf.jpg?
Comment #4
cbassig CreditAttribution: cbassig commentedYes. I uploaded it their personally and I looked in the actual folder on the server and it is there. Also, if I just change the API back to the standard GD2 it goes through its cropping and appears.
Comment #5
bignab CreditAttribution: bignab commentedI had the same problem. The problem shows up when you have clean urls enabled . It tries to find the url of the file relative to your current clean url. I fixed it by patching imageapi_imagemagick.module with:
line 195:
if ($h = proc_open($convert_path .' '. $command_args, $descriptors, $pipes)) {
to:
if ($h = proc_open($convert_path .' '. $command_args, $descriptors, $pipes,$_SERVER["DOCUMENT_ROOT"])) {
the extra argument is the current working directory to run the imagemagick convert command in.
Comment #6
drewish CreditAttribution: drewish commentedwhy aren't you just using an absolute path to convert?
Comment #7
histrion CreditAttribution: histrion commentedI've encountered the same problem. We have three other boxes running older versions of PHP 5.2 and they're fine, but proc_open() in 5.2.8 on our new machine doesn't appear to be defaulting to the current script's working directory. I can't find any config setting that should affect this, but something's obviously different.
The default wd for proc_open() appears set to /, although getcwd() returns the appropriate path.
I fixed it by changing the call to proc_open to
instead of using DOCUMENT_ROOT (which may or may not be the appropriate directory depending on your installation).
Comment #8
drewish CreditAttribution: drewish commentedmind rolling a patch?
Comment #9
drewish CreditAttribution: drewish commentedi think this is a duplicate of #360193: ImageAPI Broken - base_path() problem--well technically this was first but that one has a patch so please test it out.