Closed (duplicate)
Project:
ImageAPI
Version:
7.x-1.x-dev
Component:
ImageAPI Imagick
Priority:
Normal
Category:
Support request
Assigned:
Unassigned
Reporter:
Created:
24 Dec 2008 at 19:20 UTC
Updated:
17 Apr 2009 at 17:33 UTC
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 commentedif you enable debugging what do the commands and output look like?
Comment #2
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 commentedso did you double check that there's actually a file named sites/examplesite.com/files/leaf.jpg?
Comment #4
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 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 commentedwhy aren't you just using an absolute path to convert?
Comment #7
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 commentedmind rolling a patch?
Comment #9
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.