Posted by alimosavi on October 19, 2009 at 6:36am
11 followers
| Project: | ImageAPI |
| Version: | 6.x-1.9 |
| Component: | ImageAPI Imagick |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | reviewed & tested by the community |
Issue Summary
Hi
How i can resolve this problem :
warning: is_file() [function.is-file]: open_basedir restriction in effect. File(/usr/bin/convert) is not within the allowed path(s): (/home/httpd/irdrupal.com/httpdocs:/home/httpd/irdrupal.com/irdrupal.com:/home/irdrupal/:/tmp:/usr/share/pear:/var/lib/php/session/:/home/kloxo/httpd/script) in /home/irdrupal/irdrupal.com/sites/all/modules/imageapi/imageapi_imagemagick.module on line 162
Comments
#1
The module logic assumes that you cannot use ImageMagick if the open_basedir security restriction is enabled.
But this is not true. On my shared host, I can execute /usr/bin/convert although it is not on the allowed paths.
Therefore, I added the following check in front of the others in the function _imageapi_imagemagick_check_path in the file imageapi_imagemagick.module (line 162):
// Try it out and return without errors on success$handle = popen($path . " -version", 'r');
$im_version = fread($handle, 2096);
pclose($handle);
if (strpos($im_version, 'ImageMagick') !== FALSE) {
return $errors;
}
You can try with this. If it does not work you can also try to copy convert one of the allowed paths.
P.S. I changed Component to Imagick, because it is not related to GD, but to ImageMagick.
#2
Thanks! The above worked for me!
Imran Khan
Project Manager
New Earth Marketing
#3
#4
Automatically closed -- issue fixed for 2 weeks with no activity.
#5
yep, had to do the same today, with a client hosted on HostGo (http://www.hostgo.com ) First time this issue has given me grief, with installs of imagecache on the servers of quite a number of different hosting companies.
any chance that this patch can be added to the module itself? :-)
cheers
Peter 'Fish' Fisera
Earth Angel Consulting
#6
Thanks, #1 worked for me
#7
Love the solution alexh. Very reasonable, and absolutely correct. This patch should be reviewed for addition to the module. It's a bug fix, not so much a support request. Modifying the statuses slightly to be more accurate.
#8
I created a patch of the above could. Could I get someone to try it out, please?
The patch I posted on this number won't work, it's applied at the project level, rather than the module.
#9
Rerolled the changes to affect from the module's directory correctly to version 1.9.
#10
Resetting the que to test the patch.
#11
This one includes proper unix line endings and utf-8 encoding
#12
This solution has been accepted into the image module's imagemagick code about a week ago.
#13
This is still broken in the latest update 6.x-1.10. I updated and broke all my sites and had to search two days again for the fix cause I couldn't remember where I found it. Pasting in the code from number 1 fixed it. This time I'm going to remember where to find this fix!!!
#14
This has been tested by multiple people. Let's get it added to the next version if possible.
#15
This worked for me. Here are some simpler instructions:
imageapidirectory, make a backup copy, and then open the file:imageapi_imagemagick.modulefunction _imageapi_imagemagick_check_path($path) {$errors = array();
if (!is_file($path)) {
To:
function _imageapi_imagemagick_check_path($path) {
$errors = array();
// Try it out and return without errors on success
$handle = popen($path . " -version", 'r');
$im_version = fread($handle, 2096);
pclose($handle);
if (strpos($im_version, 'ImageMagick') !== FALSE) {
return $errors;
}
if (!is_file($path)) {