Migrating from the Beta FileMaker PHP API

This is a quickie: If you were using the beta release of the PHP API for FileMaker, there are some things you should know.

First, the beta API expires in October 7th, 2007. If you have a live site using the API, **you must update to FileMaker 9 and the new API** before then or your site will stop working. Now is the time to make the switch, before you have to do it in a pinch.

Second, there are some differences between the beta API and the final API which you may need to address. The change that affected me most is new behavior in the `getField()` method of the Record object. In at least some versions of the beta api, this method returned the raw field data unchanged. But in the final API, it will “html encode” special characters in the field. So if you have, for instance, a < in the field, the API will turn it in to &lt;, so that it shows as a proper less-than-sign on the rendered page.

This is a good change because it makes it less likely you’ll build fragile pages. But it breaks in one common case: when you have HTML in your fields that you want to render. In many situations, I allow users to enter formatted data in a FileMaker field (custom sizes, fonts, and point sizes). I then use the `GetAsCss()` function to convert this text to html-marked-up code that preserves the formatting. In this situation, I want the actual HTML to render on the page, instead of being escaped.

In this situation, you need to switch to the `getFieldUnencoded()` function in the PHP API. Just change `getField` to `getFieldUnencoded`. The object references and parameters are all the same.

>Note: Work overload meant I did not keep up on the PHP API betas as well as I should have. It is possible this change (and others) came in various beta releases, which I never bothered to test. That is very much my own problem, but I suspect there are others out there in the same boat.

I should stress that this is a *good* change to the API. And it is pretty trivial to find the places in your code where you really want un-encoded output and fix them.

If you discover other gotchas that need to be fixed, post them in the comments below. I have converted one site successfully to the new API, and it only took a couple hours to do everything.

Leave a Comment

14 thoughts on “Migrating from the Beta FileMaker PHP API

  1. 2 FYI’s to add to this that I just found on FM Forums / filemaker.com.

    1) Apparently FM accidentally placed this same expiration date on their FMS 9 release. This means that even if you are running a copy of FMS 9.0 v1 it will still expire on October 7. If you apply the 9.0 v2 path it this limitation should be rectified. Note that this applies only to FMS not FMSA.

    2) For those persons who inadvertantly deployed the beta with FMSA 8 in a production environment, there is a patch available on FM’s site to extend its life for an additional 90 days.

  2. @Alex – Thanks a lot for the heads up. Having your FMS install expire would definitely cause some headahces. Thanks for the heads up.

  3. This was a big help:

    In this situation, you need to switch to the getFieldUnencoded() function in the PHP API.

    Question: If the field data I’m rendering is a link to an external image file is there a way to set a size for the image to display? Your solution worked great for bringing it in but size is to large.

  4. @Thomas: At that point you’re not dealing with FileMaker or PHP specifics anymore. You need to turn to features of HTML. In particular, instead of linking to the image itself, link to a web page that includes the image using an <img...> tag. You can use the height and width attributes of this tag to control the size of the image on the page.

    Hope this helps!

  5. how do I add the height and width to the html when the php page only gives the php tag and not an image tag?

    I have added the width and height to the calculation in filemaker to display a photo in a certain size but I would like to do that in Html. I would like to add some rollover java to the photo and can not do that to the php.

    So I have a calculation field that provides:

    This displays the photo but I have no control over it in html.

  6. The calculated solution in filemaker is working for now for the images. I little hard to change the design but it works.

    I’m having trouble with the record list page and error

    Fatal error: Call to undefined method RecordHighlighter::getFieldUnencoded() in D:\mlsmax.com\www\eMLS\recordlist.php on line 212

    They will display on the detail page but not the list page

  7. I created one dynamic valuelist in filemaker database. In that valuelist, I selected option as “Also display values from second field”. I need to display that value list on web page using FileMaker PHP code. I do not want to use find all query.
    My code is as follows:
    setProperty(‘username’, ‘web’);
    $connection->setProperty(‘password’, ‘web’);
    $VLayout = $connection ->getLayout(‘TestLayout’);

    $vlist = $VLayout -> getValueList($valueList = ‘TestValuelist’);

    echo “”;
    echo “” . “Select” . “” ;
    foreach ($vlist as $opt)
    {
    if ($opt == ‘Test’)
    echo “” . $opt . “” ;
    else
    echo “” . $opt . “” ;
    }
    echo “”;
    ?>

  8. I created one dynamic valuelist in filemaker database. In that valuelist, I selected option as “Also display values from second field”. I need to display that value list on web page using FileMaker PHP code. I do not want to use find all query.
    My code is as follows
    require_once(“FileMaker.php”);
    $connection =& new FileMaker($database =”Example”);
    $VLayout = $connection ->getLayout(‘TestLayout’);
    $vlist = $VLayout -> getValueList($valueList = ‘TestValuelist’);
    echo “”;
    echo “” . “Select” . “” ;
    foreach ($vlist as $opt)
    {
    echo “” . $opt . “” ;
    }
    echo “”;
    ?>

  9. This was bugging me as I started working with FMS9, seeing the html tags echoed instead of being rendered. SFR is genius!!! Thanks for pointing out this ‘gotcha’.

  10. how can i work with one layout which shows values from other database layout through external data source.

    hope to hear,

  11. Antony:

    I assume you’re talking about web publishing here. If so, the PHP api has access to any field on the targeted layout that the user you’re logging in as is allowed to see. So to make this work:

    1: Make sure the php account name and password your using is set up in the external file, with a privilege set that allows access to the table(s) and field(s) you want to see.

    2: Add the fields to the layout in your main database using a relationship.

    3: Reference the fields in PHP using the fully qualified field name (Table Occurrence::Field).

    I do this all the time and it works perfectly.

    Geoff