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

drewish’s picture

if you enable debugging what do the commands and output look like?

cbassig’s picture

It 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....

drewish’s picture

so did you double check that there's actually a file named sites/examplesite.com/files/leaf.jpg?

cbassig’s picture

Yes. 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.

bignab’s picture

I 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.

drewish’s picture

why aren't you just using an absolute path to convert?

histrion’s picture

I'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

proc_open($convert_path .' '. $command_args, $descriptors, $pipes, getcwd())

instead of using DOCUMENT_ROOT (which may or may not be the appropriate directory depending on your installation).

drewish’s picture

Version: 5.x-1.2 » 7.x-1.x-dev

mind rolling a patch?

drewish’s picture

Status: Active » Closed (duplicate)

i 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.