Imagemagick

Next topic

Author	Message
John Doe	Thursday 19 April 2007 6:13:39 pm Hello! My host is not running in php safe mode but also does not allow system() calls thus Imagemagick is not working. The system() call is yet allowed to run in php-fastcgi mode which you can set up by using AddHandler or the ending .phpx. Is there any workaround to use IM with this environment like only letting the image handlers run in this mode? Let's say, is it possible to have the /lib/ezimage/classes/ directory parsed by AddHandler php-fastcgi or is it possible to rename the ezimageshellhandler.php to .phpx? Please, i really do appreciate any help on this!
Egil Fujikawa Nes	Friday 20 April 2007 3:31:38 am Hi John, I been dealing with eZ publish hosting for many years, but this is a new and very interesting issue. First of all I expect you have a good reason for using ImageMagic and not GD (that's not so hard to find). As you write the php-fast-cgi module is activated with an AddHandler filter for the extension .phpx. This means that it's Apache that decide if it's the regular php integration or the php-fast-cgi module that should be used. eZ publish in the other hand let all the request go trough index.php so simply change the extension of the file thats been included to us ImageMagic will not help. What you can try to do is to change the name of index.php to index.phpx and then run all your eZ requests trough the php-fast-cgi module, I'm not sure if this will work but it's the only workaround I can see that not require a significant code job. I would very much like to hear if this works out for you. Good luck :) Try out Free eZ Publish 4.0 Trial Hosting for 14 days: http://webdealhosting.com/ez-publish-trial-hosting High quality eZ Publish Hosting since 2001!
John Doe	Friday 20 April 2007 6:04:46 am Hi Egil, thanks for your reply! I tried renaming index.php to extension .phpx. Debug output told me about problems with var/log so I 777 this directory with whole subcontent like the log files. No more bad debug output. But if I try the URL for the admin panel, it falls back to normal site, so there has to be an error depending the URL then. After a grep of the source files, a reference to "index.php" is found in many of them so just renaming to .phpx would not do it, there always would be those little errors. So I set up an .htaccess with the content "AddHandler php-fastcgi .php". Now the index.php is handled over fastcgi without renaming. I tried that these days already but there was always some error like the admin panel fell back again or there were no writing rights to the log directory. It seems that in fcgi mode you have to change the rights in var/log as mentioned above. And to use the admin panel u should know that there is an "?" assigned to the index.php as far as I can see now (late :P), so to reach the admin panel you need to do a .../index.php<b>?</b>/your_admin_url. Then again, having made it to the admin panel, i cleared all the caches one after the other. Clicking on the "Clear" button in quick tab to the right just went to asking me if I wanted to download the index.php. Clearing cache after cache or all caches over the Design tab instead was working. Loading the a page with images the first time gives a warning "chmod() ... Operation not permitted in ... ezimagehandler.php" and an error "Error: eZImageHandler::changeFilePermissions" ""Chmod 0666 (someimagefile) failed". Loading it a second time, those warnings and errors are gone. I looked up the named files by FTP and saw that they automatically were chmod 666 so maybe this is the reason why debug output did not show warnings and errors a second time alias when they are already cached. To sum it up: AddHandler php-fastcgi in .htaccess, var/log and subcontent rights to 777, admin panel over index.php? (question mark!), weired index.php download if clicked on the wrong cache button, after clearing all caches a one time chmod() error. I will have a try if I can live with this kinda not so really satisfying solution. ;) Thanks again Egil for the information that all subscripts are running over index.php. That made me save some time on thoughts about how to change the other scripts. Have a nice day! the one who invested many many many hours in problems who shall not be there

Author

Message

Thursday 19 April 2007 6:13:39 pm

Hello!

My host is not running in php safe mode but also does not allow system() calls thus Imagemagick is not working. The system() call is yet allowed to run in php-fastcgi mode which you can set up by using AddHandler or the ending .phpx.

Is there any workaround to use IM with this environment like only letting the image handlers run in this mode? Let's say, is it possible to have the /lib/ezimage/classes/ directory parsed by AddHandler php-fastcgi or is it possible to rename the ezimageshellhandler.php to .phpx?

Please, i really do appreciate any help on this!

Egil Fujikawa Nes

Friday 20 April 2007 3:31:38 am

Hi John,

I been dealing with eZ publish hosting for many years, but this is a new and very interesting issue.
First of all I expect you have a good reason for using ImageMagic and not GD (that's not so hard to find).

As you write the php-fast-cgi module is activated with an AddHandler filter for the extension .phpx. This means that it's Apache that decide if it's the regular php integration or the php-fast-cgi module that should be used.

eZ publish in the other hand let all the request go trough index.php so simply change the extension of the file thats been included to us ImageMagic will not help.

What you can try to do is to change the name of index.php to index.phpx and then run all your eZ requests trough the php-fast-cgi module, I'm not sure if this will work but it's the only workaround I can see that not require a significant code job.

I would very much like to hear if this works out for you.

Good luck :)

Try out Free eZ Publish 4.0 Trial Hosting for 14 days:
http://webdealhosting.com/ez-publish-trial-hosting

High quality eZ Publish Hosting since 2001!

John Doe

Friday 20 April 2007 6:04:46 am

Hi Egil,

thanks for your reply!

I tried renaming index.php to extension .phpx. Debug output told me about problems with var/log so I 777 this directory with whole subcontent like the log files. No more bad debug output. But if I try the URL for the admin panel, it falls back to normal site, so there has to be an error depending the URL then.

After a grep of the source files, a reference to "index.php" is found in many of them so just renaming to .phpx would not do it, there always would be those little errors. So I set up an .htaccess with the content "AddHandler php-fastcgi .php". Now the index.php is handled over fastcgi without renaming.

I tried that these days already but there was always some error like the admin panel fell back again or there were no writing rights to the log directory.

It seems that in fcgi mode you have to change the rights in var/log as mentioned above. And to use the admin panel u should know that there is an "?" assigned to the index.php as far as I can see now (late :P), so to reach the admin panel you need to do a .../index.php<b>?</b>/your_admin_url. Then again, having made it to the admin panel, i cleared all the caches one after the other. Clicking on the "Clear" button in quick tab to the right just went to asking me if I wanted to download the index.php. Clearing cache after cache or all caches over the Design tab instead was working.

Loading the a page with images the first time gives a warning "chmod() ... Operation not permitted in ... ezimagehandler.php" and an error "Error: eZImageHandler::changeFilePermissions" ""Chmod 0666 (someimagefile) failed". Loading it a second time, those warnings and errors are gone. I looked up the named files by FTP and saw that they automatically were chmod 666 so maybe this is the reason why debug output did not show warnings and errors a second time alias when they are already cached.

To sum it up: AddHandler php-fastcgi in .htaccess, var/log and subcontent rights to 777, admin panel over index.php? (question mark!), weired index.php download if clicked on the wrong cache button, after clearing all caches a one time chmod() error.

I will have a try if I can live with this kinda not so really satisfying solution. ;)

Thanks again Egil for the information that all subscripts are running over index.php. That made me save some time on thoughts about how to change the other scripts.

Have a nice day!
the one who invested many many many hours in problems who shall not be there