You're beyond my comfort level with PHP on this one, but I think the PDF at this link may give a clue about using that PHP function more successfully:
Tim's paper contains the methods I used and tested... along with others.
If I do this same thing using my own FMSA9 and FMSA12 Mac servers I get the image displayed.
This server, however, is actually returning the contents of the field... just not encoded in the right way. I would get the same result if I had opened a photoshop jpeg document with a text editor.
The problem is how do I make it display the actual picture?
I think the PHP on the server is 5.33... not sure what version of wordpress. Perhaps it is encoding or perhaps I need to change the XHTML header...
1 of 1 people found this helpful
As I warned, you're beyond my comfort zone in PHP.
My only other thought is that the Wordpress > Support site can probably help with an encoding issue.
And you probably already thought of that, too.
Surprisingly, no... I hadn't, Thanks Stephen.
How are you using the getContainerData method? Can you provide a code snippet?
Some of the methods I used included variations on these:
<img src="ContainerBridge.php?path=<?php echo $artwork->getField('Image',0) ; ?>">
... Where ContainerBridge.php is the FileMaker PHP Example file. This has previously generated an image on my own servers.
<?php echo $fm->getContainerData('/fmi/xml/cnt/?-db=XYZ&-lay=web&-recid=3&-field=Image(1)');?>
... This one generates the text of the image as shown in pic above. It does the same thing when I use variables for the path..... I also tried it embedded in an <img>:
<img src="<?php echo $fm->getContainerData('/fmi/xml/cnt/?-db=XYZ&-lay=web&-recid=3&-field=Image(1)');?>">
At this point I don't know what is in the header... it is a wordpress include.
I am getting all the other record data, so the filemaker.php and the database access php is working just fine.
I have tried various encoding and decoding including :
<img src="ContainerBridge.php?path=<?php echo urlencode($artwork->getField('Image',0)) ; ?>">
I am wondering if it needs to be encoded as UTF-8 or ISO??? and if so where? how?
... just really going around in circles...
1 of 1 people found this helpful
Can you give this a try?
<img src="<?php echo $fm->getContainerDataURL('/fmi/xml/cnt/?-db=XYZ&-lay=web&-recid=3&-field=Image(1)');?>">
When I use that call without the <img> tag it returns the image path and used within the <img> tag it gives me a missing image.
When I open the missing image... it does give me a further clue though. I get:
When I changed the call to:
<img src="http://<?php echo $fm->getContainerDataURL('/fmi/xml/cnt/?-db=XYZ&-lay=web&-recid=3&-field=Image(1)');?>">
... it asks for a UN/PW which when entered gives me the image...
(so close.... )
I also tried :
un:pw@ before the http... but again a missing image.
-username=un&-password=pw& ... as part of the query string... but again a missing image.
Ok, so the fact that you're being challenged for credentials gives us a clue. (Note that whatever you do, you don't want to include the credentials in the URL itself.)
Check out this thread - https://fmdev.filemaker.com/message/128436#128436. In it, I described how I was able to resolve the issue. (It's kind of ugly, but it has seemed to work for many of us.)
If you need anything else, let me know.
Yes... I did get it working using an embedded username and password...
I decided though that I did not want them exposed in a URL which would occur when the image is opened in a new window/tab or downloaded.
What I did was ...
...to place the image field on a brand new layout... and turn on Guest access with restrictions to only that layout and only that field and only PHP.
Works a treat!!!!
Thanks so much Stephen and Tim for piping in... I knew I would get there but when was always the problem. I have been in dental pain for a quite a few days now and I just couldn't think straight about it anymore.
A further update to this:
The above worked for Safari and FireFox on a Mac. Chrome did not support this for security reasons. I'm told Explorer didn't either. Also when I tried it on another copy of Safari it failed.
After many iterations the following seems to work:
Guest access as described above turned on... and any-old-username and password embedded in the url as "http://un:pw@domain/path....". It didn't work when I specified a real username and password in Chrome or FF unless the Guest access was on.
Crossing fingers this works in Explorer.... Someone want to test for me? Send me a private message and a private email address to send you the link.
Thanks for posting the Guest Acct method, and the update. Sounds like another possible workaround to this problem.
There've been a few posts recently about the authentication problem when trying to display container files through the API. I think it'd be great if we all report this as a bug to FMI so hopefully it'll get fixed in some future version.
Also, FYI, http://browserstack.com is a great way to test websites in different browsers and OSes (incl. mobile simulators). Plus, you can get 3 mos. free testing of Windows browsers if you go via:
Using a guest account or trying to encode the username/password in the URL is ripe for a security breach. One look at the HTML and a hacker will know what you're doing, then it's off to the races to write their own PHP script which grabs the data from every record that's available, possibly overwriting or deleting the records. I don't think your client would be happy to know there's a massive security breach like this on their web site.
Instead, you can do one of two things:
1. Create a separate PHP file (many examples exists of the containerbridge.php file), and a call to this file is what you embed in the <img tag (within a <?php tag).
2. Within your existing PHP script, make a call to get the container data and write this data to a file in a web visible directory. You're essentially creating a cache file that the web browser will access. This speeds up page load time as only one PHP script runs and the browser can 'efficiently' handle the request to retrieve another (static) image file off the web server. Using the pkey of the image record would be an easy way to create a unique file name, but any method to create unique file names will work. You can go all crazy and only write the file if it doesn't exist or the file creation time is older than the image record mod time. Not necessary but it does speed things up a bit. Otherwise just write the file each time.
I've used both methods successfully a number of times. #2 requires a tiny bit more coding but will give the best performance.
A further update...
Explorer refused to load the image using the embedded un/pw.
I stripped this away un:pw@ and it worked. Surprisingly this time so did all the others.