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.

Comments

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.

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

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

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.

StatusFileSize
new684 bytes

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

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

StatusFileSize
new896 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.

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.

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.

Version:6.x-1.5» 6.x-1.x-dev
Status:Fixed» Active

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?

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

Status:Active» Needs review
StatusFileSize
new598 bytes

StatusFileSize
new675 bytes

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.

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.

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

that patch totally worked.

thanks

sebsebseb123, what platform are you using?

Version:6.x-1.x-dev» 7.x-1.x-dev
StatusFileSize
new1.77 KB

this actually needs to go into head first.

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.

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

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.

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!

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

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

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

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

Greets,

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.

Thanks,
Clif

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.

I use nonstandard vhost configuration

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

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

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.

StatusFileSize
new566 bytes

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

Don't we need to adjust:

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

as well?

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

Looks to me like this needs review.

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.

Thanks,
RJ

StatusFileSize
new669 bytes

#37 seems more reasonable than #33.

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.

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.

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.