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.


account-deletion-needed’s picture

Status: Postponed (maintainer needs more info) » Needs review

Ok so I have been investigating the problem a bit and it appears that the variable $convert_path which is passed to proc_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) in proc_open() needs to be set to $_SERVER['DOCUMENT_ROOT']. After that all IM commands work fine.

account-deletion-needed’s picture

Version: 5.x-1.4 » 6.x-1.5

Changing version to Drupal 6 as I've updated since posting the initial issue.

drewish’s picture

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.

account-deletion-needed’s picture

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 =)

drewish’s picture

marked #350953: Imagick Unable to Find and Convert as a duplicate since the symptoms seem identical.

drewish’s picture

896 bytes

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.

drewish’s picture

Status: Needs review » Fixed

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.

yesterday’s picture

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.


drewish’s picture

Version: 6.x-1.5 » 6.x-1.x-dev
Status: Fixed » Active
scafmac’s picture

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?

scafmac’s picture

drewish’s picture

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

drewish’s picture

Status: Active » Needs review
598 bytes
Paul Natsuo Kishimoto’s picture

Also broken for me using 6.x-1.6 on Drupal 6.11. My configuration:

  • PHP 5.2.0
  • Apache/1.3.37 (Unix) mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 mod_ssl/2.8.28 OpenSSL/0.9.7a PHP-CGI/0.1b
  • ImageMagick 6.0.7 05/03/07 Q16

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.

drewish’s picture

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.

bspellmeyer’s picture

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

sebsebseb123’s picture

that patch totally worked.


drewish’s picture

sebsebseb123, what platform are you using?

drewish’s picture

Version: 6.x-1.x-dev » 7.x-1.x-dev
1.77 KB

this actually needs to go into head first.

deviantintegral’s picture

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.

perusio’s picture

Patch in #19 fixes also the same bug with imageapi 5.x-1.5.

drewish’s picture

Status: Needs review » Fixed

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.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Brian@brianpuccio.net’s picture

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.


tehwalrus’s picture

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


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 :)

drewish’s picture

tehwalrus, try the -dev as was advised above. it's probably time to roll new releases.

dbu’s picture

i stumbled over this bug. don't you want to put out a new release sometimes? it is confusing, especially if you don't know enough about linux to realise that the message looks like a issue with wrong working directory...

i just had to replace $_SERVER['DOCUMENT_ROOT'] with base_path() in imageapi_imagemagick.module ...

bitbaud’s picture

Title: ImageAPI ImageMagick doesn't work in Windows 7 » ImageAPI Broken - base_path() problem
Version: 7.x-1.x-dev » 6.x-1.6
Priority: Normal » Critical
Status: Closed (fixed) » Needs work


I had the problem of with the 6.x-1.6 version of imageapi the module with drupal 6.x-stable. The problem only appeared for me when trying to upload the images for ubercart products. Changing the variable: ' $_SERVER['DOCUMENT_ROOT'] ' to ' base_path() ' in the imageapi_imagemagick.module file of the imageapi module fixed it.


drewish’s picture

Version: 6.x-1.6 » 6.x-1.x-dev
Status: Needs work » Postponed (maintainer needs more info)

I'm not certain this is a problem with the current -dev releases. Test the new release.

vectoroc’s picture

I use nonstandard vhost configuration

<VirtualHost *:80>
      DocumentRoot /var/www
    RewriteEngine on
    RewriteCond %{HTTP_HOST}   ^example.com[NC]
    RewriteRule   ^/(.*)$ /var/www/example.com/$1

So current working dir does not equal $_SERVER['DOCUMENT_ROOT']
Why can't you simply use getcwd() here?

drewish’s picture

vectoroc, at this point I'm not sure what's the least bad answer for most people. I don't even know where to begin testing all the permutations on this.

brianmercer’s picture

566 bytes

This is legion80's patch from http://drupal.org/node/615966#comment-2686242 which substitutes getcwd(), redone in a standard patch format.

drewish’s picture

Don't we need to adjust:

 $convert_path = 'start "window title" /D'. escapeshellarg($drupal_path) .' /B '. escapeshellarg($convert_path);

as well?

RobLoach’s picture

Status: Postponed (maintainer needs more info) » Needs review

Looks to me like this needs review.

jahmal’s picture

Patch #33 seems to do the job for us. We are using nonstandard apache configuration (Using VirtualDocumentRoot) and getcwd() seems to be ok with it. Can we have this committed to stable (or at least -dev) branch ?

Does it still work for people with standard DocumentRoot setting ?

@drewish: Your comment is valid, I think this should also use getcwd() but I have no way to test it on Windows (for which that part of code applied). I'm attaching patch with this change.

I think it needs community testing, it would be good to test few user cases:
- Sites with Drupal root residing in DocumentRoot
- Sites using Windows IIS and Windows Apache
- Sites with files in subdirectories

We have tested on VirtualDocumentRoot and all seems good.


jahmal’s picture

669 bytes
drewish’s picture

#37 seems more reasonable than #33.

mikeytown2’s picture

Document_root is not the correct way to do this
#1042918: Imagick Fails when used from drush
It fails when using drush.
Not sure if getcwd is the correct way to do this either.

Dane Powell’s picture

I recently moved a Drupal installation to VirtualDocumentRoot configuration, and ImageAPI started throwing a bunch of errors about being unable to find files. Patch #37 solved the problem.

drewish’s picture

Status: Needs review » Fixed

Committed the patch from #37 to 6.x-1.x.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.