Images Not Visible in 8.2.1 (2017) [SOLVED]
Permalink
This is a new install of 8.2.1 on Dreamhost.
I have looked at some threads from 2010 to 2013 describing this problem but I just want to see if there is any updated information before I go hacking away at this.
I can upload .png and .jpg with no problem but there is no thumbnail and when I select the picture file and try to add it. I get a frame with no picture, just the name of the picture.
Screenshots attached. Any help much appreciated.
9-15-2017 UPDATE AND SOLUTION (I HOPE)!
In Dreamhost sharing you will have different PHP configuration files i.e.:
/.php/7.0
/.php/7.1
et cetera
I navigated to the folder for the PHP version you are using. In my case that was 7.0.
In that folder there is a file called phprc (ATTEMPT 1) (no extension) that looks like this:
I edited phprc (ATTEMPT 4) to read as follows:
Please note that when I installed 8.2.1 I first had phprc (ATTEMPT 2) as follows:
and that didn't work (perhaps I had a typo -- not sure), so I modifed phprc (ATTEMPT 3) this way:
And that got me past the Concrete5 prerequisites screen, but after the installation was complete uploaded images did not work correctly using the Concrete5 dashboard. I suspect that it would have installed using ATTEMPT 4. But that's just a guess.
Oh after you edit the phprc file Dreamhost documenation says you need to restart php services and you can do that by panel>manage domains>edit the domain you are working with, then without making any changes to the domain select the [save changes] button.
I have looked at some threads from 2010 to 2013 describing this problem but I just want to see if there is any updated information before I go hacking away at this.
I can upload .png and .jpg with no problem but there is no thumbnail and when I select the picture file and try to add it. I get a frame with no picture, just the name of the picture.
Screenshots attached. Any help much appreciated.
9-15-2017 UPDATE AND SOLUTION (I HOPE)!
In Dreamhost sharing you will have different PHP configuration files i.e.:
/.php/7.0
/.php/7.1
et cetera
I navigated to the folder for the PHP version you are using. In my case that was 7.0.
In that folder there is a file called phprc (ATTEMPT 1) (no extension) that looks like this:
; {{{ The following lines were automatically added by DreamHost zend_extension=opcache.so ; }}} That's all from DreamHost
I edited phprc (ATTEMPT 4) to read as follows:
; {{{ The following lines were automatically added by DreamHost extension = fileinfo.so zend_extension=opcache.so ; }}} That's all from DreamHost
Please note that when I installed 8.2.1 I first had phprc (ATTEMPT 2) as follows:
; {{{ The following lines were automatically added by DreamHost zend_extension=opcache.so extension = fileinfo.so ; }}} That's all from DreamHost
and that didn't work (perhaps I had a typo -- not sure), so I modifed phprc (ATTEMPT 3) this way:
; {{{ The following lines were automatically added by DreamHost zend_extension=opcache.so zend_extension = fileinfo.so ; }}} That's all from DreamHost
And that got me past the Concrete5 prerequisites screen, but after the installation was complete uploaded images did not work correctly using the Concrete5 dashboard. I suspect that it would have installed using ATTEMPT 4. But that's just a guess.
Oh after you edit the phprc file Dreamhost documenation says you need to restart php services and you can do that by panel>manage domains>edit the domain you are working with, then without making any changes to the domain select the [save changes] button.
Those file sizes seem suspiciously low. Could something have interrupted the upload process? Can you upload a non-image file and have it show the correct file size?
Probably images with a large filesize (above 2mb). Upload times out.
Hi Gents:
Thanks for trying to help me with this. The filesize doesn't seem to matter. The range of sizes I have tried are between 6.2kb to 19.1mb. As you can see in this video:
http://greatreasons.org/files/videos/V.greatreasonsimagefail-2017-0...
Notice that the uploader recognizes the image and seems to create a thumbnail. Some of the older posts about images not working talk about MySQL settings. I am wondering if the php is working just fine but the image is not getting stored into MySQL?
Thanks for trying to help me with this. The filesize doesn't seem to matter. The range of sizes I have tried are between 6.2kb to 19.1mb. As you can see in this video:
http://greatreasons.org/files/videos/V.greatreasonsimagefail-2017-0...
Notice that the uploader recognizes the image and seems to create a thumbnail. Some of the older posts about images not working talk about MySQL settings. I am wondering if the php is working just fine but the image is not getting stored into MySQL?
The problem seems to have something to do with the thumbnail creation process, because I can [View] the photos in Concrete>Files but I can't add them to the website. I get a [class "finfo" not found] error] when I try to upload files using the >Remote Files option or when I try to > Properties > Rescan.
Here is a video that shows the error:
https://greatreasons.org/files/videos/V.greatreasonsimagefail-2017-0...
I thought I had resolved this problem during the install, but it seems 8.2.1 may not be 100% compatible with the Dreamhost workaround I stumbled into.
See:https://www.concrete5.org/community/forums/installation/class-finfo-...
Here is a video that shows the error:
https://greatreasons.org/files/videos/V.greatreasonsimagefail-2017-0...
I thought I had resolved this problem during the install, but it seems 8.2.1 may not be 100% compatible with the Dreamhost workaround I stumbled into.
See:https://www.concrete5.org/community/forums/installation/class-finfo-...
finfo is a php class
http://php.net/manual/en/class.finfo.php...
Does dreamhost allow you to turn on php classes in their control panel?
This may help
https://help.dreamhost.com/hc/en-us/articles/214205858-How-do-I-enab...
Ed
http://php.net/manual/en/class.finfo.php...
Does dreamhost allow you to turn on php classes in their control panel?
This may help
https://help.dreamhost.com/hc/en-us/articles/214205858-How-do-I-enab...
Ed
Hi Ed, no that did not solve it. I still need help.
I thank you for the input. I do appreciate the effort.
Yes I already had followed Dreamhost instructions to enable fileinfo. By doing so I was able to get the install to work. The install was failing at the prerequisites check and if you tried to install anyway, it would fail towards the end. As above, I recounted this here:https://www.concrete5.org/community/forums/installation/class-finfo-...
Anyway, it seems that the Concrete5 thumbnail code won't accept Dreamhost's implementation of fileinfo for reasons beyond my paygrade. I really need help here. Thanks.
I thank you for the input. I do appreciate the effort.
Yes I already had followed Dreamhost instructions to enable fileinfo. By doing so I was able to get the install to work. The install was failing at the prerequisites check and if you tried to install anyway, it would fail towards the end. As above, I recounted this here:https://www.concrete5.org/community/forums/installation/class-finfo-...
Anyway, it seems that the Concrete5 thumbnail code won't accept Dreamhost's implementation of fileinfo for reasons beyond my paygrade. I really need help here. Thanks.
Long shot..
Try changing the Image Manipulation Library
../index.php/dashboard/system/files/thumbnails/options
Try changing the Image Manipulation Library
../index.php/dashboard/system/files/thumbnails/options
I have the exact same problem... I can see images when I approve a stack in the dashboard 'stacks and blocks' but while editing only the image title placeholder shows. When editing a content block or image block the same deal...only when the page is live will the image show.
I had the exact same problem and it was not a PHP problem.What happened was some photos would upload normally and other wouldn't. Same size range, normal jpg files usually, really nothing to it but it would just fail every time while others would upload normally.
In my case, I was able to upload them after opening them in an image editing software (Photoshop) and saving them again.
I don't know, maybe there was so messed up header or something like that in the image itself.
I can't guarantee it will work for you but it worked for me most of the time. Worth a shot I guess.
You could also check in your C5 logs and in your server's PHP logs for error messages that could give you a clue.
In my case, I was able to upload them after opening them in an image editing software (Photoshop) and saving them again.
I don't know, maybe there was so messed up header or something like that in the image itself.
I can't guarantee it will work for you but it worked for me most of the time. Worth a shot I guess.
You could also check in your C5 logs and in your server's PHP logs for error messages that could give you a clue.
I still need help. I tried loading the images in GIMP and Inkscape and then exporting them. Then upload, of course. It didn't work.
If there is certain special requirements for getting pictures to work after all prerequisites have been met on the install then that seems like a Concrete5 problem. If it's problem with PHP and how hosts implement shared hosting and so you will need a dedicated server or something like that, then hopefully the Concrete5 team can let us know.
Anyway, I will try to get into the logs tomorrow if I still can't figure it out. My mind is hurting from this right now. :(
If there is certain special requirements for getting pictures to work after all prerequisites have been met on the install then that seems like a Concrete5 problem. If it's problem with PHP and how hosts implement shared hosting and so you will need a dedicated server or something like that, then hopefully the Concrete5 team can let us know.
Anyway, I will try to get into the logs tomorrow if I still can't figure it out. My mind is hurting from this right now. :(
I seem to recall about three threads recently in which finfo fails on Dreamhost. Is anyone on Dreamhost getting c5 image uploads working perfectly (regardless of format)? If not, I'd be wondering whether Dreamhost has misconfigured their finfo.
FWIW, the video indicates that the upload didn't go well; the progress bar below the image was red, whereas it should go green. This could indeed indicate a thumbnailing problem. (Or could it be resizing on uploading?).
Could you attach an image that won't upload for you? Then others can try it on other hosts and see if it works for them. If you, the problem will be narrowed down.
Could you attach an image that won't upload for you? Then others can try it on other hosts and see if it works for them. If you, the problem will be narrowed down.
If the Concrete5 team could get in touch with Dreamhost I think that they might be more inclined to work with a big vendor then a small potato like me.
Per Gondwana's suggestion: If anyone wants to try the same pictures that I am unable to get to work through the Concrete5 upload they are all in this directory:
https://greatreasons.org/images/...
FWIW, I can use any of these images by manual FTP to the Concrete site and simply referencing to them as an external image. Obviously, that's not an ideal CMS solution.
Per Gondwana's suggestion: If anyone wants to try the same pictures that I am unable to get to work through the Concrete5 upload they are all in this directory:
https://greatreasons.org/images/...
FWIW, I can use any of these images by manual FTP to the Concrete site and simply referencing to them as an external image. Obviously, that's not an ideal CMS solution.
Having suggested that you make your images available, I figured I'd better try one. ;)
Basically, it worked for me - see first four attached images at various stages through the process. That was using the gd extension for thumbnailing. Resizing on upload worked too.
When I switched to image magick, I got the last two results attached. This looks similar to the problem you're seeing, so check that you're not using image magick. You probably aren't; I still suspect the problem is with Dreamhost's fileinfo.
I doubt that the concrete5 core team will contact your host on your behalf.
Basically, it worked for me - see first four attached images at various stages through the process. That was using the gd extension for thumbnailing. Resizing on upload worked too.
When I switched to image magick, I got the last two results attached. This looks similar to the problem you're seeing, so check that you're not using image magick. You probably aren't; I still suspect the problem is with Dreamhost's fileinfo.
I doubt that the concrete5 core team will contact your host on your behalf.
Concrete5 should get involved for the benefit of Concrete5 because I am pretty sure this is a problem for everyone at Dreamhost that tries to use 8.2.1. I think Dreamhost's one-click install is way back to 5.6 or something like that. Yes, I would benefit if it was resolved but so would all Dreamhost + Concrete5 customers as well as the issue coming up over and over again here in the community forums.
That being said. I immediately fell in love with Concrete5 and I appreciate the community support. Thank you for testing my files for me! I don't know what imagemagik is so I'll start looking into that. Thanks again everyone!
Update: I got an email with the link to the thumbnail settings. I was using GD. I switched to Imagemagick and no luck. Switched again, no luck. :(
That being said. I immediately fell in love with Concrete5 and I appreciate the community support. Thank you for testing my files for me! I don't know what imagemagik is so I'll start looking into that. Thanks again everyone!
Update: I got an email with the link to the thumbnail settings. I was using GD. I switched to Imagemagick and no luck. Switched again, no luck. :(
I went to ./index.php/dashboard/reports/logs and found this :
Sep 15, 2017, 10:04:24 AM Exceptions Tom Exception Occurred: home/dreamhostusername/greatreasons.org/concrete/vendor/league/flysystem/src/Adapter/Local.php:311 Class 'finfo' not found (0)
So, I think it's pretty clear that this is a Concrete5 - Dreamhost fileinfo compatibility issue that involves the thumbnail code. But also, even though the file can be viewed on the dashboard files page, the image is not being loaded when editing a page.
Sep 15, 2017, 10:04:24 AM Exceptions Tom Exception Occurred: home/dreamhostusername/greatreasons.org/concrete/vendor/league/flysystem/src/Adapter/Local.php:311 Class 'finfo' not found (0)
So, I think it's pretty clear that this is a Concrete5 - Dreamhost fileinfo compatibility issue that involves the thumbnail code. But also, even though the file can be viewed on the dashboard files page, the image is not being loaded when editing a page.
If you look in your 'Environment Information' in your site's c5 dashboard, do you see 'fileinfo' listed as a php extension? If you don't, this is definitely not a c5 problem: no php application would be able to see the finfo class.
I had a look at your phpinfo() dump and compared it to mine. I didn't see any problems there (unfortunately).
Pragmatically speaking, I think you'll get a faster resolution if you take it on yourself. c5 staff don't even look at these forums. You could try your luck on the c5 slack channel:
http://concrete5.slack.com
I had a look at your phpinfo() dump and compared it to mine. I didn't see any problems there (unfortunately).
Pragmatically speaking, I think you'll get a faster resolution if you take it on yourself. c5 staff don't even look at these forums. You could try your luck on the c5 slack channel:
http://concrete5.slack.com
It is working now! Hopefully, it's not a fluke. :D
I want to thank Gondwana, c5dragon, edbeeny, MarcYBB, and mnakalay. All of your suggestions encouraged me and helped me understand C5 a bit better. Eliminating possibilities and checking the logs and documentation really forced me to focus on the Dreamhost fileinfo - phprc angle. Thanks again everyone.
I put the solution in my original post so hopefully that will help other Dreamhost and shared host folks.
I want to thank Gondwana, c5dragon, edbeeny, MarcYBB, and mnakalay. All of your suggestions encouraged me and helped me understand C5 a bit better. Eliminating possibilities and checking the logs and documentation really forced me to focus on the Dreamhost fileinfo - phprc angle. Thanks again everyone.
I put the solution in my original post so hopefully that will help other Dreamhost and shared host folks.
Thank you for sharing.
What I'd still love to understand is why some images upload and others don't (they do on my local install) as well.
Oh well...
What I'd still love to understand is why some images upload and others don't (they do on my local install) as well.
Oh well...
@mnakalay, I'm loathe to try to help you because you know way more than me! However, if you attach an image or two that don't work for you, I'd be happy to try them.
@Gondwana you at least figured out it had something to do with PHP extensions. I just kept staring at my screen cursing and put it on my "that's life" shelf :(
I attached images in my message below. Thanks for helping
I attached images in my message below. Thanks for helping
If give us a link to them I'll try them on my setup as well. My workaround until I got this solved was to create a subdirectory via ftp and then just create a regular content block and link to the image inside of a paragraph marker. A pain in the butt, yet it got the images up while I sorted out a solution.
Well done! That was some fine detective work. I did overlook the aspect that finally got you over the line; ie, that there can be multiple php.ini or equivalent files. It seems that Dreamhost doesn't make it easy; all I have to do is put a tick in a tickbox and CPanel takes care of updating the relevant php.ini equivalents and restarting php.
@Gondwana and @TomJClark thank you both for your offer. I am attaching an archive with 2 images in it.
Originally I had several images refusing to upload so just to make sure I kept trying the same images again and again.
In the end, only these 2 consistently refused to be uploaded.
It is not a matter of size, I have bigger images that were uploaded successfully.
The only thing I didn't try was to upload them separately but since they are uploaded in a queue it shouldn't be an issue.
One thing I noticed is after the upload fails, the files do appear in the file manager but without a thumbnail and with a size of 0 ko as it did for @TomJClark. AND if I select them to rescan them, the process fails right away with a "memory exhausted" message which again shouldn't be happening since other bigger images are uploaded successfully.
Originally I had several images refusing to upload so just to make sure I kept trying the same images again and again.
In the end, only these 2 consistently refused to be uploaded.
It is not a matter of size, I have bigger images that were uploaded successfully.
The only thing I didn't try was to upload them separately but since they are uploaded in a queue it shouldn't be an issue.
One thing I noticed is after the upload fails, the files do appear in the file manager but without a thumbnail and with a size of 0 ko as it did for @TomJClark. AND if I select them to rescan them, the process fails right away with a "memory exhausted" message which again shouldn't be happening since other bigger images are uploaded successfully.
@mnakalay, I think I know what's going on — and you provided the clue.
Your file didn't work for me. It isn't a large file in terms of file size (MB), but it IS a large image in terms of pixels. I'm guessing that the thumbnailer tries to do its thing by uncompressing the image in memory, manipulating the pixels, and then recompressing. Ergo, the more pixels, the more memory is required. I tested this theory with some files that were large in px but small in MB. They failed.
Short-term options would be to try to increase the memory available to php, or to upload smaller-px images.
Really, c5 should check for, and properly handle, this error condition because it's going to happen a lot.
Your file didn't work for me. It isn't a large file in terms of file size (MB), but it IS a large image in terms of pixels. I'm guessing that the thumbnailer tries to do its thing by uncompressing the image in memory, manipulating the pixels, and then recompressing. Ergo, the more pixels, the more memory is required. I tested this theory with some files that were large in px but small in MB. They failed.
Short-term options would be to try to increase the memory available to php, or to upload smaller-px images.
Really, c5 should check for, and properly handle, this error condition because it's going to happen a lot.
@Gondwana I am not sure that is the whole answer.
For instance one of the failing images has dimensions of 2419 x 3216 and weighs in at 2.11 Mo
But I have another image which has dimensions of 2471 x 3216 and weighs in at 2.41 Mo so it's bigger in weight AND in dimensions and still it uploaded successfully from the first attempt while uploading other images at the same time.
Now your test seems to prove dimensions are a factor; I just don't think it is the only one.
Last but not least, there are 2 resizing processes taking place on upload. First, you have a setting to make sure images don't go beyond a certain dimension. Any image wider than that setting gets resized. Then after that's done and the image is uploaded, the thumbnailing comes into play. That's 2 possible failing points. We would need to pinpoint which one is the culprit.
This is getting interesting ;)
For instance one of the failing images has dimensions of 2419 x 3216 and weighs in at 2.11 Mo
But I have another image which has dimensions of 2471 x 3216 and weighs in at 2.41 Mo so it's bigger in weight AND in dimensions and still it uploaded successfully from the first attempt while uploading other images at the same time.
Now your test seems to prove dimensions are a factor; I just don't think it is the only one.
Last but not least, there are 2 resizing processes taking place on upload. First, you have a setting to make sure images don't go beyond a certain dimension. Any image wider than that setting gets resized. Then after that's done and the image is uploaded, the thumbnailing comes into play. That's 2 possible failing points. We would need to pinpoint which one is the culprit.
This is getting interesting ;)
I have 'automatic resizing' on upload deselected, so thumbnailing alone can cause the problem. I wonder if those use the same approach to resizing. It would make sense.
I do recall a pull request recently to release memory between image resizes/thumbails/something. I don't know if that was before or after 8.2.1 release; if it hasn't made it into the versions we're using yet, it could be another variable.
Because we're dealing (I think) with a memory issue, some variation is to be expected. The amount of memory available for in-memory canvases will vary depending on how much memory is being used for other things at the time (and especially if previously-used memory hasn't been released!). If we see a significant statistical correlation between pixel size and thumbnail failures, I think that's good enough to start pointing the finger.
Methinks it behooves us to work out how c5 should behave if thumbnailing/resizing fails.
I do recall a pull request recently to release memory between image resizes/thumbails/something. I don't know if that was before or after 8.2.1 release; if it hasn't made it into the versions we're using yet, it could be another variable.
Because we're dealing (I think) with a memory issue, some variation is to be expected. The amount of memory available for in-memory canvases will vary depending on how much memory is being used for other things at the time (and especially if previously-used memory hasn't been released!). If we see a significant statistical correlation between pixel size and thumbnail failures, I think that's good enough to start pointing the finger.
Methinks it behooves us to work out how c5 should behave if thumbnailing/resizing fails.
Yes maybe you're right, it might be worth looking into it
@mnakalay, I think this is the issue you're hitting:
https://github.com/concrete5/concrete5/issues/5852...
I can XDebug my way through the code using your images, and that's where it dies.
https://github.com/concrete5/concrete5/issues/5852...
I can XDebug my way through the code using your images, and that's where it dies.
I get this error when trying to rescan bigdec15.jpg:
"Allowed memory size of 94371840 bytes exhausted (tried to allocate 12288 bytes)"
and for xz10.jpg
"Allowed memory size of 94371840 bytes exhausted (tried to allocate 31118017 bytes)"
I apologize for taking so long to get back to you, I am so out of the habit of checking email nowadays I forgot to log in once I had my problem solved. Anyway, I don't know enough about pictures to figure out why it takes so much memory to process those thumbnails. I tried converting the latter image using GIMP to .png and lower quality .jpg and still got the errors. So, I am thinking the workaround is getting some sort of conversion software where you can really tweek things and then do some research from there.
FWIW If this was my issue I would grasp at straws along these lines. It seems to me that in the older pictures would have like 32 available colors per pixel and from there it went exponentially higher? I honestly don't remember and it's definitely not in my wheelhouse. But it sounds like the metadata of your container is saying that this picture has a bazillion colors in it, but when JPG compresses it actually, most of those are filtered out. That's why the file is so small compared to the potential size? So, if you just can convert that metadata container to less colors then it might work. Other than that, somehow it seems you have to allocate more memory via php settings or your host? I don't have any idea how that can be done.
"Allowed memory size of 94371840 bytes exhausted (tried to allocate 12288 bytes)"
and for xz10.jpg
"Allowed memory size of 94371840 bytes exhausted (tried to allocate 31118017 bytes)"
I apologize for taking so long to get back to you, I am so out of the habit of checking email nowadays I forgot to log in once I had my problem solved. Anyway, I don't know enough about pictures to figure out why it takes so much memory to process those thumbnails. I tried converting the latter image using GIMP to .png and lower quality .jpg and still got the errors. So, I am thinking the workaround is getting some sort of conversion software where you can really tweek things and then do some research from there.
FWIW If this was my issue I would grasp at straws along these lines. It seems to me that in the older pictures would have like 32 available colors per pixel and from there it went exponentially higher? I honestly don't remember and it's definitely not in my wheelhouse. But it sounds like the metadata of your container is saying that this picture has a bazillion colors in it, but when JPG compresses it actually, most of those are filtered out. That's why the file is so small compared to the potential size? So, if you just can convert that metadata container to less colors then it might work. Other than that, somehow it seems you have to allocate more memory via php settings or your host? I don't have any idea how that can be done.
