Wednesday 06 June 2012 1:02:35 pm - 25 replies
Hi every body,
I have another problem, after the one you helped me to solve few weeks ago here.
The site was working pretty well (a "4.6", community 2012.2), and I made few security updates, I guess the problems may come from here, but impossible to be sure, since I can't tell the problems apprear just after or not.
After the previous issue, the images were OK, and eZ generated the variations without problems.
Right now, no way ! As soon as I integrate a new picture in the back-office, it is correctly imported on the serveur, but I can't see it in the front or back office (I can only see it in FTP mode).
I thought it could be a problem of policies, but event if the image, and all the folder of "/var" are in 777, no changes...
The settings seems to be OK, all variations are set-up.
An attribute(show) of an image in a related object show "NULL" for the variations
Do you have any ideas where I should look ? Thanks in advance,
Arnaud.
PS : Excuse my poor english, I'm french
Wednesday 06 June 2012 1:06:32 pm
I just checked error.log, and found lots of :
[ Jun 06 2012 12:43:04 ] [193.253.43.127] eZImageManager::createImageAlias:Failed converting var/plain_site/storage/images/mediatheque/images/image-test-arnaud/1323-5-fre-FR/image-test-Arnaud_reference.jpg to alias 'medium' in directory 'var/plain_site/storage/images/mediatheque/images/image-test-arnaud/1323-5-fre-FR'
in the debug, I have those 2 warning and error :
Warning: eZImageShellHandler::convert Jun 06 2012 13:38:03
Failed executing: /usr/bin/convert 'var/(...)/image.jpg' '-quality' '75' '-geometry' '300x300>' 'JPEG:var/(...)/image.jpg', Error code: 1
Error: eZImageManager::createImageAlias Jun 06 2012 13:38:03
Failed converting var/(...) to alias 'large' in directory 'var/(...)'
When I open a console, and I do direct in SSH the previous command
/usr/bin/convert 'var/(...)/image.jpg' '-quality' '75' '-geometry' '300x300>' 'JPEG:var/(...)/image.jpg'
it works without problem !!!
could-it help ? Any idea ?
Modified on Wednesday 06 June 2012 2:24:25 pm by Arnaud Boulai
Thursday 07 June 2012 1:15:57 pm
First thanks to all for your help, I don't feel too alone !
@ Daniel : Yes I guess it's a problem of permissions, but as far as I'm not very good at console mode and server administrations, I really have difficulties to understand how to solve that
@Steven :
I tried the chown (BTW I changed the ";" to a point). As a result, I had Operation not permitted on every file
I believe the second line was to empty all cache... I say "I believe" because one of the firt line of ezcache.php is "require 'autoload.php';" and, very strangely, the server respond "Warning : main(autoload.php) [<a href='function.main'>function.main</a>]: failed to open stream: No such file or directory in /homepages/34/d408362589/htdocs/eplefpa/bin/php/ezcache.php on line 12"
I did it manually (through putty by makin a "rm * -rf" in cache folder).
Finally, I still can get variations
I also need to add that I'm am running eZ on a mutualised server @ 1and1 (sorry)...
Thursday 07 June 2012 6:06:54 pm
It's got to be a permissions problem... who is your apache server running as? The chown www-data:www-data - (should be a : d'oh typo) will only work if it matches the user:group of your process.
Login with putty again and do a ps -ef|grep "apache" to see who owns the process and use that as the user.
Once you are sure that the files are owned by the user:group that is running the apache process, you may also want to do this to your <varDir> directory:
find <varDir> -type d -exec chmod 775 '{}' \;
find <varDir> -type f -exec chmod 664 '{}' \;
varDir is of course set by [FileSettings]varDir= in the relevant site.ini file.
Thursday 07 June 2012 6:18:31 pm
The autoload problem could also be related to permissions...
you did this as you from the command line? Do you not have read/write permissions for autoload/ezp_kernel.php and var/autoload/ezp_extension.php?
Actually the message doesn't make much sense to me since line 12 of autoload.php for eZ 4.6 is a comment...
// ini_set( 'include_path', ini_get( 'include_path' ). ':../ezcomponents/trunk' );
Did this somehow get uncommented? With 4.6 the components are embedded in lib/ezc are you overriding that in your config.php? Specifically on line 21? Line 33 also better be true or commented out.
Friday 08 June 2012 4:59:40 pm
Hi there ! I'm getting mad
I explain :
I first wanted to do what you said first (ps -ef|grep "apache". This is what I got as an answer :
1337394 3069 25600 0 16:48 pts/0 00:00:00 grep apache
I then made this :
find var/plain_site -type d -exec chmod 775 '{}' \;
and had no mistake !
The same for the other line :
find var/plain_site -type f -exec chmod 664 '{}' \;
and again had no mistake
But...
I still have no variation
I then decided to try something totally different : I installed the latest version (2012.5) and made a lot of parameters, then I launch it, put an image, and... ! Again, it doesn't work
I'm afraid it comes from the server and its parameters, but can't find help from them...
I will then try to reinstall a new 2012-5 version and will try to put a picture direct, without any modification/parameter, and will see... If you have any other idea, of course, I will be glad to test it !
thanks in advance !
Edit : Well, I installed a standard 2012.5 with no modification, and the problem is still there
I will try to install an older version...
Modified on Monday 11 June 2012 6:35:01 pm by Arnaud Boulai
Saturday 09 June 2012 12:29:11 am
Hi
It's a common issue on 1and1 cuz ImageMagick is consuming too much memory so you are required to limit the number of threads it can create.
I'm not exactly sure of where to put the fix but can you try this?
It should look like this:
function createImageAlias( $aliasName, &$existingAliasList, $parameters = array() ) { putenv("MAGICK_THREAD_LIMIT=1"); $fname = "createImageAlias( $aliasName )";
Modified on Saturday 09 June 2012 12:31:16 am by Quoc-Huy NGUYEN DINH
Monday 11 June 2012 9:59:00 am
I can't believe how strong some people are, here
Huy, it seems you found the solution !!
I am always amased of such... every thing ! kindness, cleverness, and lots of other thing that make people so kind (I would say much more things in french but I need more vocabulary in english to say all what I think and feel !!!).
Right now, my problem seem to be OK, and I am very grateful ! Many thanks to all, and specialy to Huy for the tip !
Best regards,
Arnaud.
Monday 11 June 2012 4:21:06 pm
Can you do me a favor?
Can you undo the change I suggested and try this one? I don't have access to 1and1 server to test it myself
Thanks
Monday 11 June 2012 5:55:29 pm
Great.
I'm planning to create a fix for this and make it available as a pull request.
Would be nice if we can include it into a next version of eZ Publish so that other people can benefit of it and you don't have to modify the PHP file every time you update eZ Publish.
Monday 11 June 2012 5:58:54 pm
Works fine also
Which one do you suggest to keep ?? The previous version seems to work fine since a lot of picture was integrated with no complains But this method seems ok also, I try it successfully
(But maybe it was necessary to empty cache first ?)
Thanks again !
Modified on Monday 11 June 2012 6:00:32 pm by Arnaud Boulai
Monday 11 June 2012 9:53:27 pm
The 2nd method is better than the first. But this 3rd method is better than the 2nd
Can you please try this one, if it works I will submit it to eZ Systems.
Might have some bugs as I'm editing on iPad...Huy
Modified on Monday 11 June 2012 10:12:18 pm by Quoc-Huy NGUYEN DINH
You must be logged in to post messages in this topic!