I have some FileMaker PHP calls embedded in a wordpress template. When I call the getContainerData() function, the result is the raw text of an image... not the image.
This is what I get (see pic)
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.
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...
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.
<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...
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.
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.
Mark I wanted to avoid externally written files.... that just creates something a search engine can find... no way. I've done it that way many times and this time it was important to keep all the data safely tucked away in the database.
Creating an external containerdata.php file made absolutely no difference to the problems I was having... which I wouldn't have had at all if it had been a single machine config without the php being embedded inside wordpress.
Frankly, I think the problems were related to the cache between the two machines.. not getting a fresh call to the database for the image.
Yes I did generate the img tags using PHP.
No there is no security risk using the guest account. They don't have write access and they can't access the link in the first place unless they log on first. There is only PHP access to that layout so it is not as if someone can open it using FM client. Your solution creates a MUCH bigger security risk.... and exposes the image url to the hacker in a much less secure way.
As I mentioned, the cache is an option if you want to increase performance. No one is saying you have to use it. If you treat all images on your page the same, then the cache isn't an issue. If you're treating those images stored in FM as special, then yes, a cache probably wouldn't be the best idea. Of course once the page has loaded, there's nothing stopping the end user from saving those 'special' FM-stored images to their own device, pulling them out of the browser cache, or even doing a screen shot.
I think we're going to have to agree to disagree on the guest account being a risk because I believe there is an issue: If I know the IP address of your server and guest access is enabled, that's all I need to grab every container field from the table. Please see the attached FM database and PHP script. It's a working example of how to pull the container data given only guest access. The FM database has Admin access with username of test and password of test.
Your solution creates a MUCH bigger security risk.... and exposes the image url to the hacker in a much less secure way.
Are you referring to something you see in my code, or again referencing the cache? If the cache, I already explained that isn't a security issue if you don't consider the container field data as different than any other image that might be served. However, if you see a security issue in the code I posted I would be eager to know what it is so that I may fix it.
I'd still like to understand the problem you're having that is 'forcing' you to abandon the standard security model with the API. To me it sounds like it might possibly be the encoding of the Word Press page (perhaps the DOCTYPE is 'different'?) that is confusing things. I've never run into what you're seeing so I'm rather curious to know what it could be. I've never had to integrate with WordPress, but I once did a project with Joomla and that didn't create any encoding issues like you appear to have. One thing I don't know about your set up: are your container fields stored internally or externally in the FM 12 database?
Retrieving data ...