Image upload - Fails to generate thumbnail.

Hello Everyone. I'm currently putting together my third site using Concrete5 and I have to say I'm completely impressed. My clients love it and so do I.

I do have a problem I'm hoping someone can help me with. I have a client that will be uploading photos into an image gallery and he sent me the photos. They're LARGE (about 2.5M) and they seem to be messing up the file manager image upload. I've tried both the single upload and the multi-upload with the same results.

The file upload screens don't appear to work correctly. They hang after a short time. However, when I refresh the file manager page I can see that the files uploaded, they just didn't create the thumbnail. I can tell because I can click on the images and choose view and I can see them in their entirety. The thumbnail however is just the generic one.

I've looked at things like max_execution and upload filesizes and I think I'm in good shape there. I'm hoping someone can offer me a some advice on this.

Here are my environment settings:
# concrete5 Version

# concrete5 Packages
Sortable Fancybox Gallery (1.13).

# concrete5 Overrides
themes/jj, tools/phpinfo.php

# Server Software
Apache/2.2.11 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.8i DAV/2 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/

# Server API

# PHP Version

# PHP Extensions
bcmath, calendar, cgi, ctype, curl, date, dom, exif, filter, ftp, gd, gettext, hash, iconv, imap, json, libxml, mbstring, mcrypt, mhash, mime_magic, mysql, mysqli, openssl, pcre, posix, pspell, Reflection, session, SimpleXML, soap, sockets, SPL, standard, tidy, tokenizer, wddx, xml, xmlreader, xmlrpc, xmlwriter, xsl, zip, zlib.

# PHP Settings
log_errors_max_len - 1024
max_execution_time - 5
max_input_nesting_level - 64
max_input_time - -1
memory_limit - 16M
post_max_size - 20M
safe_mode - Off
safe_mode_exec_dir - /usr/local/php/bin
safe_mode_gid - Off
safe_mode_include_dir - <i>no value</i>
sql.safe_mode - Off
upload_max_filesize - 20M
mysql.max_links - Unlimited
mysql.max_persistent - Unlimited
mysqli.max_links - Unlimited
pcre.backtrack_limit - 100000
pcre.recursion_limit - 100000
session.cache_limiter - nocache
session.gc_maxlifetime - 7200
soap.wsdl_cache_limit - 5
safe_mode_allowed_env_vars - PHP_
safe_mode_protected_env_vars - LD_LIBRARY_PATH

Thanks in advance for any help you can offer!

View Replies:
Remo replied on at Permalink Reply
you might want to increase memory_limit, 16M isn't a lot! Try something like 64M
screame1 replied on at Permalink Reply

Thanks for responding and for the suggestion. You are right - that wasn't much. I upped it to 64M and unfortunately got exactly the same result.

Smaller images are working fine so I know there's something here that's bombing out. I can't find any errors in either error logs in the public_html directory or via cpanel. Can you think of anyplace else I might be able to find an error log?

I even fired up Firebug and watched the network traffic as it passed. The post sends correctly but the server responds back pretty quickly with a blank response.

Thanks in advance for any other help you can offer!

Remo replied on at Permalink Reply
I can upload a pic ~4MB without a problem.. Are you sure it's not the file itself? A bad header? Do all large pictures fail the same way?
screame1 replied on at Permalink Reply
Interesting suggestion so I gave a couple of other things a try. I found a couple of ~2 Meg photos from a different source (my digital camera) and tried to upload them. Exact same results.

I went back and tried a smaller file (~300k) and it worked fine.

I still stumped. Any other ideas?

Thanks again!
Brainakazariua replied on at Permalink Reply
Up the max_execution_time to like 30.

The max_execution_time is the Maximum execution time of each script, in seconds. yours is set to 5 which is probably too short.

of that alone doesn't solve it then also up your max_input_time. mine is set to 60 and I have no problems.
screame1 replied on at Permalink Reply
You know - I noticed that too. The weird thing is that my max_execution_time is set to 90 seconds in my php.ini file. Can you think of anything that would be overriding this in Concrete5?
Brainakazariua replied on at Permalink Reply
Is is the php.ini on your enviroment or is it the one at server level? the one at the server lever overrules your enviromental one. It might also be that your server has more then one php.ini. Mine has one located somewhere in the Zend area and one at the php5 area.
The one in the Zend area isn't used in my case but it's still there.

in other words, you might be editting the wrong file or one which get overruled by one at a higher level. if you can't find it I suggest you contact your host to check it for you.
screame1 replied on at Permalink Reply 1 Attachment
I actually set it via WHM - they have an interface for that. Just to check something though I did go ahead and run a phpinfo from the root directory of this install. I've attached it here. It shows the max execution at 30 seconds.

I really think you're on to something because I timed how long it took the script to time out and it was right at the 5 second mark. If phpinfo is picking it up at 30 I wonder where the 5 seconds is coming from in Concrete5?

Brainakazariua replied on at Permalink Reply
can't seem to find it. it might be overruled.

try adding this line to your site.php:
and then try again.

This is explained here:
screame1 replied on at Permalink Reply
Tried it - sorry, no luck. I really think it's got to do with the 5 second limit. I've been digging through all of the models and controllers looking for an override in one of them but I don't see anything.

Just as an FYI I went back through my other sites I've built and they have the same problem - and the same 5 second limit.

Thanks again for the helpful advice!
Remo replied on at Permalink Reply
why do you think it has to do with the time limit? You'd see that in firebug and besides, my vServer with 128MB of memory needs less than a second to create a thumbnail for a picture which is 5MB
screame1 replied on at Permalink Reply
It might not be the timeout - that's just the best clue I had right now. I based that on watching the request end abruptly at the 5 second mark using Firebug.

The server gives me nothing to go on. I get no reply back at all from the post.

The server is plenty capable - it's a dedi and here's her specs:
# Intel Xeon 3040 (Dual Core)
# 2 GB DDR2 Memory
# 2 x 250 GB Hard Drive

The load is currently tiny on this box.

I'm still open to ANY other suggestions. I'm at a loss as to explain this.

Remo replied on at Permalink Reply
just to be sure, can you go to the file manager, click on more, activate the tab "Add Remote File" and enter this URL:

it's the first big picture I could find. This works without a problem for me.

About the time limit, if there's 30 seconds in your php.ini, what does a page with phpinfo(); tell you?
screame1 replied on at Permalink Reply

Thanks for continuing to try to help. Your image you suggested uploaded fine. Here is a link to an image that would not work for me:

I think what I may be running into is a memory issue. I'm just not getting any feedback saying so. I tried upping the allowed memory to 128 but it still didn't work.

Would you mind trying that image and see if it works for you?

Interestingly enough I did try this fix:

and it worked fine. I just hate to have to change core code.

Thanks again!
Remo replied on at Permalink Reply
This picture works for me (128M memory limit) but only if I download it first, not sure why I couldn't upload it using the "Add Remote File" feature.

Do you have the pictures on your local computer when you upload them?

I did see a short spike in my memory usage but 128M works for me!
screame1 replied on at Permalink Reply

Well, now I'm really at a loss. I'm uploading them from my PC (well, Mac actually) using Firefox 3.0.5. That file won't work for me for anything.

For the life of me I have no idea why.

I guess for now I'll use the fix and change the core code but I'd sure still like to find a better answer. I even upped my memory to 256M and still no better.

Thanks for taking so much time to try to help. Hopefully I can return the favor one day.

Remo replied on at Permalink Reply
I think that's the point where I'd start the debugger... No clue either!
DeWebmakers replied on at Permalink Reply
I found the origin of the 5 seconds in max_execution_time.
In the file:


On line 505 the code is:

However, this didn't solve any of our problems, but at least we now know where those 5 seconds come from.
Kiesel replied on at Permalink Reply
You may wanna read this thread, I had about the same Problem:

....sorry, just saw that you found that post already by yourself ^^

We use this fix now since this post and it always worked fine. If you copy the importer.php file to libraries/file then you leave the original core code intact.

I suggested after my problem to use ImageMagick for the core, but so far nothing happened :(

This is a memory problem, quick and simple. GD-lib is not the best choice to make this sort of image-manipulations.
Freundschaft replied on at Permalink Reply
well you could always hack your code to use imagemagick instead of GD in the image helper class

inserting something like
exec("/usr/bin/convert $originalPath -thumbnail {$finalWidth}x{$finalHeight} $newPath");

right before the

res = @imageCopyResampled($image, $im, 0, 0, $crop_src_x, $crop_src_y, $finalWidth, $finalHeight, $oWidth, $oHeight);

and commenting out
/*$res = @imageCopyResampled($image, $im, 0, 0, $crop_src_x, $crop_src_y, $finalWidth, $finalHeight, $oWidth, $oHeight);
         if ($res) {
            switch($imageSize[2]) {
               case IMAGETYPE_GIF:
                  $res2 = imageGIF($image, $newPath);
               case IMAGETYPE_JPEG:
                  $compression = defined('AL_THUMBNAIL_JPEG_COMPRESSION') ? AL_THUMBNAIL_JPEG_COMPRESSION : 80;
                  $res2 = imageJPEG($image, $newPath, $compression);
               case IMAGETYPE_PNG:
                  $res2 = imagePNG($image, $newPath);

should do the trick