Although installed on the server Gallery3 doesn't detect ImageMagick.
I discovered that "which convert" doesn't give a result although convert is in the path (/usr/bin). I think that's a security setting of the server (no root access).
To explicitly search at the rigth location, I changed the detection to use graphics_toolkit_path if it's set.
In graphics.php:
// ImageMagick
$path = $graphics_path=="" ? exec("which convert") : $graphics_path."/convert";
Regards, Carsten
Posts: 16503
You don't need root access. "which convert" works on my shared host who's running FreeBSD. Are you running Linux (what distro?), Mac, FreeBSD, xxxBDS, Solaris or something else?
Also, you shouldn't have had to edit that file, you should be able to set the path under Admin > Settings > Advanced settings
If that setting doesn't work, then I don't believe you're using the latest experimental code.
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here
Posts: 6
I've only ftp access. I'm not sure about the distribution. Gallery reports Linux 2.6.25.20-25.1-pae and an unknown Apache version.
The problem is, that even an exec("ls -a"); gives no result, so it's a very restricted server.
Without this change the graphics_toolkit_path is added to the enviroment PATH and exec("which convert") is called. But since exec("which convert") never gives a result, convert isn't deteced. Adding "/convert" to the graphics_toolkit_path directly gives the correct value for $path without any search.
I'm using the RC2. The problem is, that exec("which convert") never returns a result. And Gallery 3.0 RC2 only adds the users configuration to PATH instead of accepting the setting.
Carsten
Posts: 6
For Gallery 3.0 it's slightly different:
325c325,329
< $path = exec("which convert");
---
> if ( module::get_var("gallery", "graphics_toolkit_path") ) {
> $path = module::get_var("gallery", "graphics_toolkit_path")."/convert";
> } else {
> $path = exec("which convert");
> }
349c353,357
< $path = exec("which gm");
---
> if ( module::get_var("gallery", "graphics_toolkit_path") ) {
> $path = module::get_var("gallery", "graphics_toolkit_path")."/gm";
> } else {
> $path = exec("which gm");
> }
Posts: 16503
Looks like your host doesn't have ImageMagick installed, but GraphicsMagick instead. Why not just select that toolkit from Admin > Settings > Graphics?
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here
Posts: 6
No, you are wrong.
ImageMagic is installed at /usr/bin and works fine with Gallery2 and with my change in graphics.php
(GrapicsMagic isn't selectable in Admin > Settings > Graphics: PHP's open_basedir restriction prevents Gallery from using it.).
The problem is, that exec("which convert") always returns an empty string.
Since exec("ls -la") also returns an empty string I'm sure, that my provider has "secured" the server.
Why does graphics.php searches for convert if the user has set graphics_toolkit_path? If convert is in the PATH (and the which command works) the user wouldn't touch graphics_toolkit_path. If it doesn't the users setting from Admin > Settings > Advanced settings is used.
Carsten
Posts: 7934
Meh. If they're locking down exec then we're not going to be able to call out to ImageMagick anyway. You can always just replace the which() call in graphics.php to hardcode the path to the convert binary to see if that works for you.
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git
Posts: 6
No, exec itself works fine. exec("convert -v"); correctly return the version.
It looks as if they have redirected any linux command, that may be used to examine the server, to a stub.
As you can see in my code I haven't hardcoded the path, but make use of Gallery's variable graphics_toolkit_path.
Carsten
Posts: 7934
If you hardcode a path, does it work?
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git
Posts: 6
Since simply using Gallerys variable graphics_toolkit_path, instead of the result of the which command, works fine, it would also work.
The above code works fine.
When graphics_toolkit_path is still unchanged empty, the which command is used to detect where convert is installed.
If graphics_toolkit_path is set, it simply accepts the users setting. If the users setting would be wrong, this would be detected in the next step.
In my case I've set graphics_toolkit_path to /usr/bin
At the Graphics settings Gallery shows, that "ImageMagick version 6.3.7 is available in /usr/bin"
Carsten
Posts: 7934
We could do that. Please file a ticket for this and I'll work on it when I get a chance. thanks!
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git
Posts: 554
New user. Same problem. Same Solution. Thanks.
I've been comparing Coppermine and Gallery and am likely to go with Gallery for the next major installation. Interestingly Coppermine has the same problem, and even thought its config page has the Imagemagick variable correct in my ISP's one-click install, it still doesn't work. So one more reason to go with Gallery.
undagiga
Edit: I spoke too soon. Yes, Gallery3 can find Imagemagick using this technique, but something goes wrong when importing images. The import runs but the thumbnails and intermediate images are not built. User support at the hosting firm assures me that it's at /usr/bin/conver and working.
Posts: 7934
@undagiga: please start a new topic for your problem and we'll get ImageMagick working for you. Don't forget to post the contents of your gallery3/var/logs logfiles.
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git
Posts: 554
Thanks. Will do. Have to say I really like the friendly and helpful tone on this forum. Much better than over at the Coppermine forum.
Undagiga
Posts: 7934
Thanks, we try!
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git
Posts: 22888
Just a FYI if you are searching:
https://sourceforge.net/apps/trac/gallery/ticket/1555 is now fixed.
Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team