Using ImageMagick when proc_open() is disabled

seems like some pointless "security" to me. if they let you call exec() then proc_open() isn't any more dangerous. proc_open() was chosen for it's cross platform compatibility and ability to capture stderr output to log errors. you could hack it to use exec() or something like that but it won't be done as part of an official release.

Were you successful at hacking using exec()? I would love to be able to use ImageCache, but my server also doesn't allow proc_open().

I actually have the same problem with my host: Proc_open is disabled for security reasons and the host will not enable this function, instead refers to it's availability under FastCGI-Mode. To enable the cgi mode for my site, I now have two possibilities:

a) enable it for the entire Drupal installation via .htaccess
b) enable it solely for the PHP-Script that calls to the functions that are disabled in PHP5 for security-reasons...

Option a) is not actually a solution, as it would slow-down the whole drupal-site enormeously, so I thought about a possibility to turn FastCGI mode on only for the image.imagemagick.inc file, as it calls the proc_open() function.

Now my Question is: how can I do that?

As I read on the hosts support page i should rename the corresponding .php file to .phpx - of course this will not be of any effect in this case, as I have an .inc file. Renaming to .inc.phpx will not work either, except if I could find the hook where the image.imagemagick.inc is being included.

Next option I thought about is: enabling cgi mode only for the .inc files... but applying
AddHandler php5-cgi .inc
in either root/drupal/.htaccess or root/drupal/includes/.htaccess would not work...

Do you maybe have some solution how to get this running withouth having to put the whole Drupal site on fast-cgi mode?

I have *no* idea about imagemagick. I'll commit patches if they appear sane and have been tested, but unless the other maintainer is more clued up than me, this is one the community will have to figure out.

Thanks a lot for your reply, joachim. I hope someone following the issues around this (besides really nice!) module has some idea how to get around this, as I only found messages like "use the GD-image module instead of imagemagick" around this topic.

So my next question would be: is the module - even if a temporary solution - fully working without the imagemagick thing?

For the answer to that, see the issue queue, and the issue called 'Image 1.0' in particular.

We are very close to a full 1.0 release; and yes, with GD most things work fine, just a few minor bugs to tidy up.

I had close to the same issue on a site I support for someone. They moved hosting because of very poor service, things like MySQL beign down for 8+ hours and ignoring support emails.

Anyway, the new provider had imagemagick loaded in /usr/bin, and you could exec and run it from PHP, but the checks to see if it was in /usr/bin would fail, you could not open files outside of your account. You are being put in chroot jail.

I made a directory outside of the of the www_root but still under the account called our_bin and just copied /usr/bin/convert to that location, and then told Drupal that's where to find it.

It's a bit of hack, but it works.

@jriedel and anybody with experience of using imagemagick: please feel free to start a documentation page in this module's handbook about working with imagemagick.

@jriedel

I wonder if it will solve this issue. If proc_open and exec is disabled, you are IMHO lost. OTOH hand you can cope the "is not in include path issue" by copying though.

As originally in 2009, this works as designed. See #1.

Would it be possible to switch to the imagick class instead of using convert?
http://de3.php.net/manual/en/book.imagick.php

@Kai: Interesting. Please open a feature request for http://drupal.org/project/imagemagick - thanks.