ImageAPI ImageMagick doesn't work in Windows 7
drimsun - January 17, 2009 - 12:57
| Project: | ImageAPI |
| Version: | 7.x-1.x-dev |
| Component: | ImageAPI Imagick |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Description
I know Win7 is still beta, but I was wondering if anyone got ImageMagick to work with ImageAPI?
Although the path to convert.exe can be set, ImageAPI fails to communicate with ImageMagick. That is, there's no output coming back from ImageMagick (version information, errors, ...) nor are images processed, they're uploaded 1:1. ImageMagick works fine from the command prompt, though.
At first I thought there might be something wrong with Win7 permissions, but after trying out different settings the problem remained.

#1
Ok so I have been investigating the problem a bit and it appears that the variable
$convert_pathwhich is passed toproc_open()in_imageapi_imagemagick_convert_exec()(imageapi_imagemagick.module: line 194) is the culprit.If its value is changed from start "windows title" /D"path_to_drupal_root" /B "path_to_convert" to simply convert, ImageAPI can read out Imagemagick's version info just fine.
However, because the image file paths in IM commands are relative to the web root directory,
$cwd(current working directory) inproc_open()needs to be set to$_SERVER['DOCUMENT_ROOT']. After that all IM commands work fine.#2
Changing version to Drupal 6 as I've updated since posting the initial issue.
#3
drimsun, are you able to test this under XP? I'm reluctant to make a change like this without testing the previous versions and I don't have a windows box anymore.
#4
Hi drewish,
I just tested the attached patch on Windows XP/7 and Linux CentOS 4.0 with ImageAPI, ImageCache and im_raw. Everything seemed to work fine.
PS: The patch is just meant for highlighting the change =)
#5
marked #350953: Imagick Unable to Find and Convert as a duplicate since the symptoms seem identical.
#6
This patch doesn't change the $convert_path variable but sets the current working directory. I'm not going to remove the full path because you need to be able to specify which binary you want even if it's not in the system path.
#7
i went ahead and committed the last patch to HEAD, DRUPAL-6--1, and DRUPAL-5 since it's a clear improvement. if you're still having problems finding the path on windows let's re-open the issue.
#8
Yo, this patch doesn't work for folks like myself with a drupal install in a subfolder of $_SERVER["DOCUMENT_ROOT"]. Maybe you should use something like $base_path.
Thanks.
#9
#10
This patch appears to break imagemagick on a D5 site using ImageAPI 5.x-1.5. When I upgraded to the latest version, all of sudden it could no longer find the source images even though nothing has changed.
I've reverted this one line of the patch and the problem went away. My server is running Linux with Php 5.1.6. Not sure if that is related or not. I'll try to figure out some more details. Shall I open another issue for 5.1.6?
#11
More info & patch #441586: Patch for 6.x-1.x-dev breaks imageapi_imagemagick on multisite configurations on Linux
#12
i'm going to close #441586: Patch for 6.x-1.x-dev breaks imageapi_imagemagick on multisite configurations on Linux and keep the discussion over here since this fix caused the problem
#13
here's scafmac's patch from #441586: Patch for 6.x-1.x-dev breaks imageapi_imagemagick on multisite configurations on Linux
#14
Also broken for me using 6.x-1.6 on Drupal 6.11. My configuration:
Under my web root (/home/example/public_html) I have a directory named 'drupal'. Requests to the webroot are redirected via configuration in /home/example/public_html/.htaccess to /home/example/public_html/drupal/index.php
As a result, not even scarfmac's suggested patch works. $_SERVER['DOCUMENT_ROOT'] is "/home/example/public_html" and base_path() returns "/", so ImageMagick still doesn't know about the "drupal" directory in the path.
The attached patch, however, does work. I have stolen some code from
conf_path()to determine the base path of the Drupal installation. It should probably be checked on a server without my .htaccess trickery, and also on a Windows server, so that the original bug isn't reintroduced. At the moment I am not able to do so.#15
Yeah we're going to need some testing on that. Also going to need some comments explaining what's going on there. I'd also like an isset() in the ?: operation.
#16
The patch in 14 fixes the problem for my drupal installation in a subdirectory below $_SERVER['DOCUMENT_ROOT'] (Drupal 6.11, ImageAPI 6.x-1.6, Apache/2.2.9 (Ubuntu) PHP/5.2.6-2ubuntu4.2 with Suhosin-Patch).
#17
that patch totally worked.
thanks
#18
sebsebseb123, what platform are you using?
#19
this actually needs to go into head first.
#20
The patch in #19 fixes the issue for me having a site in a subdirectory. I'm using MAMP on OS X, and will be testing the site on a FreeBSD server shortly.
#21
Patch in #19 fixes also the same bug with imageapi 5.x-1.5.
#22
okay, committed to HEAD, DRUPAL-6--1, and DRUPAL-5. everyone please try out the -dev release and make sure it's still working for you.
#23
Automatically closed -- issue fixed for 2 weeks with no activity.
#24
Just wanted to chime in that I had this problem (on Ubuntu and Debian) and updating to the dev version (I've got the May 29 one) fixes it for me with no apparent ill side-effects.
Thanks!
#25
Was this ever committed to a stable branch? 1.6 is still showing as the latest stable version, and this has broken my dev setup in MAMP/OS X (i.e. it couldn't see the files, and reverting to 1.5 fixed the problem).
please take a look at threads at
http://drupal.org/node/519348
and linked from there, and get back to us poor end users with some info! :) I explain my setup and fix in more detail there.
Thanks for the hard work guys, once I get this mod working I will never have to try and write a gallery site again :)
#26
tehwalrus, try the -dev as was advised above. it's probably time to roll new releases.