I am saving images in my db field like data:image/jpeg;base64,/9j/4AAQSkZJRgABAgAAAQABAAD/2wBDAAg......
When I display the images using
<cfimage action="writeToBrowser" source="#myField#"> on a normal page it works fine. When using in a cfdocument it doesn't work. I have seen some similar issues but haven't seen any of them work for me. I tried <img src="#myField#" /> but without any luck. Anyone get this working?
Thanks
When I've seen this before it was the CF 'browser' on that server not being able to connect to the
/CFFileServlet/_cf_image/_cfimg-...PNGURL over loopback on that box. The exact cause and solution will depend upon how your web server, site config, SSL, firewall, routing, DNS are all set up.Have you looked at error logs in CF Admin for the requests with the image errors? If you get no clues there then one way to help diagnose where it's failing is to wrap your
<cfimage action="writeToBrowser"code in a<cfsavecontent>or<cfxml>tag to extract the src URL of the temp image written, and then see what result you get if you try and hit that same URL with acfhttpcall from the server - you should hit the same problem that cfdocument is getting, but you'll be able to dump out any errors to troubleshoot.Depending upon the cause in your case, one of the following methods should work:
Other lesser workarounds if you don't have access to solve above environment type issues:
a) rewrite the src URL from a relative URL to an absolute
file:///URL when used with cfdocument only.b) if there is a
localhostmapping to your site (on port 80 or otherwise) that is visible on your server, then you can try rewriting the src URL to use that instead of the FQDN.c) instead of using writeToBrowser, write the cfimage output to a path of your choice that you can prove works with cfdocument/cfhttp and output your own img tag to serve the image from that path.
In my experience you'll see a lot of posts around about cfdocument and image paths and using
localUrl=true- but where cfimage writeToBrowser is involved I have always found I needed to uselocalUrl=falseand rely on absolute URLs.