Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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.
Comment | File | Size | Author |
---|---|---|---|
#37 | imageapi_360193.patch | 669 bytes | jahmal |
#33 | imageapi_615966_360193.patch | 566 bytes | brianmercer |
#19 | imageapi_360193.patch | 1.77 KB | drewish |
#14 | imageapi_imagemagick_path.patch | 675 bytes | Paul Natsuo Kishimoto |
#13 | imageapi_patch.txt | 598 bytes | drewish |
Comments
Comment #1
account-deletion-needed CreditAttribution: account-deletion-needed commentedOk so I have been investigating the problem a bit and it appears that the variable
$convert_path
which 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.Comment #2
account-deletion-needed CreditAttribution: account-deletion-needed commentedChanging version to Drupal 6 as I've updated since posting the initial issue.
Comment #3
drewish CreditAttribution: drewish commenteddrimsun, 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.
Comment #4
account-deletion-needed CreditAttribution: account-deletion-needed commentedHi 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 =)
Comment #5
drewish CreditAttribution: drewish commentedmarked #350953: Imagick Unable to Find and Convert as a duplicate since the symptoms seem identical.
Comment #6
drewish CreditAttribution: drewish commentedThis 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.
Comment #7
drewish CreditAttribution: drewish commentedi 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.
Comment #8
yesterday CreditAttribution: yesterday commentedYo, 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.
Comment #9
drewish CreditAttribution: drewish commentedComment #10
scafmac CreditAttribution: scafmac commentedThis 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?
Comment #11
scafmac CreditAttribution: scafmac commentedMore info & patch #441586: Patch for 6.x-1.x-dev breaks imageapi_imagemagick on multisite configurations on Linux
Comment #12
drewish CreditAttribution: drewish commentedi'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
Comment #13
drewish CreditAttribution: drewish commentedhere's scafmac's patch from #441586: Patch for 6.x-1.x-dev breaks imageapi_imagemagick on multisite configurations on Linux
Comment #14
Paul Natsuo Kishimoto CreditAttribution: Paul Natsuo Kishimoto commentedAlso 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.Comment #15
drewish CreditAttribution: drewish commentedYeah 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.
Comment #16
bspellmeyer CreditAttribution: bspellmeyer commentedThe 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).
Comment #17
sebsebseb123 CreditAttribution: sebsebseb123 commentedthat patch totally worked.
thanks
Comment #18
drewish CreditAttribution: drewish commentedsebsebseb123, what platform are you using?
Comment #19
drewish CreditAttribution: drewish commentedthis actually needs to go into head first.
Comment #20
deviantintegral CreditAttribution: deviantintegral commentedThe 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.
Comment #21
perusio CreditAttribution: perusio commentedPatch in #19 fixes also the same bug with imageapi 5.x-1.5.
Comment #22
drewish CreditAttribution: drewish commentedokay, 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.
Comment #24
Brian@brianpuccio.net CreditAttribution: Brian@brianpuccio.net commentedJust 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!
Comment #25
tehwalrus CreditAttribution: tehwalrus commentedWas 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 :)
Comment #26
drewish CreditAttribution: drewish commentedtehwalrus, try the -dev as was advised above. it's probably time to roll new releases.
Comment #27
dbu CreditAttribution: dbu commentedi 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 ...
Comment #28
bitbaud CreditAttribution: bitbaud commentedGreets,
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
Comment #29
drewish CreditAttribution: drewish commentedI'm not certain this is a problem with the current -dev releases. Test the new release.
Comment #30
drewish CreditAttribution: drewish commentedmarked #615966: ImageMagick reported an error: convert: unable to open image `files/images/snacks n drinks_0.thumbnail.jpg': Permission denied. as a duplicate.
Comment #31
vectoroc CreditAttribution: vectoroc commentedI use nonstandard vhost configuration
So current working dir does not equal $_SERVER['DOCUMENT_ROOT']
Why can't you simply use getcwd() here?
Comment #32
drewish CreditAttribution: drewish commentedvectoroc, 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.
Comment #33
brianmercer CreditAttribution: brianmercer commentedThis is legion80's patch from http://drupal.org/node/615966#comment-2686242 which substitutes getcwd(), redone in a standard patch format.
Comment #34
drewish CreditAttribution: drewish commentedDon't we need to adjust:
as well?
Comment #35
RobLoachLooks to me like this needs review.
Comment #36
jahmal CreditAttribution: jahmal commentedPatch #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
Comment #37
jahmal CreditAttribution: jahmal commentedComment #38
drewish CreditAttribution: drewish commented#37 seems more reasonable than #33.
Comment #39
mikeytown2 CreditAttribution: mikeytown2 commentedDocument_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.
Comment #40
Dane Powell CreditAttribution: Dane Powell commentedI 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.
Comment #41
drewish CreditAttribution: drewish commentedCommitted the patch from #37 to 6.x-1.x.