Changes to PHP Installations with FileMaker Server

Earlier this year Claris announced that they were deprecating the bundling of PHP with FileMaker Server and would no longer be installing PHP with future versions of FileMaker Server for macOS and Windows. This impacts anyone who is using the bundled version of PHP on their FileMaker Server for use with Custom Web Publishing and the FileMaker PHP API.

With a number of recent releases of FileMaker Server this has now been completed as follows:

Windows: starting with the FileMaker Server 19.2.1 update PHP is no longer installed with FileMaker Server for Windows – you should preserve your existing PHP installation first by backing up the PHP folder and restoring it after the upgrade is complete. See the Claris Engineering Blog link below for instructions on installing PHP on Windows as well as a link to a Powershell script for automating this.

macOS: starting with version 19.4.1, FileMaker Server no longer installs a PHP engine on macOS. FileMaker Server upgrades will not remove a previously installed PHP engine, but new installations will no longer provide PHP.

We provide PHP files for use with Webhooks with most of our FileMaker integration solutions, including:

We generally provide 2 versions of these php files:

  1. for use with the older FileMaker PHP API
  2. for use with the newer FileMaker Data API

The FileMaker Data API is the newer replacement for the older PHP API and requires FileMaker Server v17 or later. Existing PHP files for both APIs will continue to work but if you are setting up a new FileMaker Server for Windows or macOS that does not have PHP installed you have a few options:

  1. install PHP for Windows Servers (see links below)
  2. host the PHP file on another web server running PHP (you will need to include the PHP API files if you are using the older PHP API) and make any adjustments to the hostname to point to the FileMaker Server
  3. change from using the FileMaker PHP API to the Data API and also host the PHP files on another web server running PHP and make any adjustments to the hostname to point to the FileMaker Server

We’ve been hosting our PHP webhooks files on Amazon Lightsail for a number of years, but any web server running PHP will do the job.

You can get more information on the changes to PHP Bundling at the following links:

Easier PDF Creation using PHP with FileMaker Server 16

If you’ve been doing Custom Web Publishing with the FileMaker PHP API and needed to generate a PDF report you haven’t had many simple options. You can use one of the available PHP PDF classes such as TCPDF or FPDF which require specifying x and y coordinates, fonts and text to output in certain positions on the page, or setup a “robot” FileMaker Pro client that runs in a loop looking for new jobs to process.

Developers have been requesting the ability to generate PDF files server-side for many years, and from my conversations with FileMaker, Inc. engineers it was the number one feature request. FileMaker, Inc. were finally able to deliver on this with the release of the FileMaker 16 platform earlier this year, which included the following new features related to PDF and printing from FileMaker Server:

  • the Print script step now allows you to create PDFs in web browsers with FileMaker WebDirect
  • the Print Setup script step now allows you to specify PDF options for the Print script step and Save Records As PDF script step on FileMaker Server and FileMaker WebDirect
  • the Save Records as PDF script step now allows you to save PDFs with FileMaker Server and FileMaker WebDirect

If you look at the documentation for the Save Records as PDF script step you will see that is only compatible with FileMaker Server and FileMaker WebDirect  and not compatible with Custom Web Publishing (CWP), which is used by the PHP API when running FileMaker scripts. At this point you might be inclined to assume that there is nothing helpful in these changes for CWP/PHP developers, but there is a way to leverage the Save Records as PDF support under FileMaker Server from a PHP page.

The solution to this requires the Perform Script On Server script step (PSoS) which is CWP compatible. At this point it’s important to mention that PSoS does require the fmapp extended privilege to be enabled for your PHP/CWP users and their associated Privilege Sets. If your PHP users don’t normally access the database using a FileMaker Pro client then you may need to make some changes to your OnFirstWindowOpen script to limit their access (e.g. lock and hide the toolbar, navigate to a blank layout etc).

With some planning you can implement a solution that works like this:

  1. you have a PHP script – e.g. printReport.php – which includes a Print PDF Report button
  2. when a user clicks this button it performs a FileMaker script using the PHP API newPerformScriptCommand method. Let’s call this script Create PDF Report on Server
  3. the Create PDF Report on Server script is run as a CWP script (remember this script cannot create a PDF on its own). It includes a Perform Script On Server step which performs another script running under FileMaker Server which handles the Print Setup/Save Records as PDF steps and generates the PDF file and stores it in a container field (or passes the PDF back as Base64 encoded text using the Base64Encode function). Let’s call this script Save PDF
  4. the Create PDF Report on Server receives the script result from the Save PDF script – if you’re passing the PDF as Base64 encoded data you can set a container field using the Base64Decode function. Now that you have the PDF in a regular container field you can exit the FileMaker script and your printReport.php can use the getContainerData method to retrieve the PDF and either display this in the browser or download it

This might look complicated but I was able to implement this in a couple of hours for a client that needed to generate PDFs for a PHP/CWP solution. Before implementing this I would recommend you first become familiar with the server side printing/PDF changes in FileMaker Server 16 – a great place to start is the found in the App Innovations space of the FileMaker Community. Download the 05_Server side PDF file which is part of DemoKit16 – a collection of tools aimed at helping demonstrate and explore new features of the FileMaker 16 Platform (brought to you by the World Wide Solutions Consulting team at FileMaker, Inc.). Upload this file to your FileMaker v16 Server and run through the examples and see how the Print Setup and Save Records as PDF script steps work under FileMaker Server 16. I ended up using these scripts:

  • [btn] How – Inventory Report – request report from server
  • [sbr] How – Inventory Report – get report as PDF (PSoS)

as the basis for my CWP scripts with only a few minor modifications, such as setting and retrieving various script parameters related to the records I was creating a PDF for.

The PHP code for this looks like this:

$scriptName = 'Request Invoice PDF'; 
$scriptParams = $orderID;  
$scriptObject = $fm->newPerformScriptCommand('WebOrders', $scriptName, $scriptParams); 
$scriptResult = $scriptObject->execute(); 
if(FileMaker::isError($scriptResult)) { $scriptError = 'Perform Script Error: '. $scriptResult->getMessage() . ' (' . $scriptResult->code . ')'; 
} else { 
$scriptError = ''; $record = $fm->getRecordById('WebOrders', $recid); 
$url = urlencode($record->getField('zv_Container_gr')); 
$fileName =  $orderID. ' Order Invoice.pdf'; 
$downloadLink = 'downloadFile.php?fileName='.$fileName.'&path='.$url; 

The downloadFile.php script simply retrieves the container data (PDF in this example) and does a force download of the PDF file to the user’s downloads folder. You could also change this to display the PDF in either the current tab or in a new tab as required.

Here’s a screenshot of the Request Invoice PDF script (have simplified this to show just the relevant steps for this technique):

and here’s the screenshot of the (simplified once again) Create Invoice PDF script that runs as the PSoS script:

I’m setting the generated PDF into a global container field in the Create Invoice PDF script as I don’t need to store the PDF file permanently in the database as this can be generated at any time, however you could also store the PDF in a regular container field in a new record etc as required and avoid having to Base64Decode/Encode the PDF data. It’s also worth remembering that you can’t use the PSoS script to set the PDF into a global field, as global fields are unique to each clients “session” so the CWP script and the PSoS script are each running in their own session, which is why you need to use the Base64Decode/Encode functions.

I’m looking forward to implementing this in existing CWP solutions which required complex FileMaker layouts to generate the PDF that weren’t easily created using the available PHP PDF classes. If you have any questions please leave a comment below.

Custom Web Publishing Changes in FileMaker Server v16

If you’re using Custom Web Publishing (CWP) with FileMaker Server v16 (PHP and XML) there are some changes in FileMaker Server v16 that you should be aware of that could break the functionality of your solution.

A client of ours recently upgraded their FileMaker Server to v16 which has a component that uses the FileMaker PHP API . One aspect of this involves a PHP page performing a FileMaker script which downloads files from an external service to the temp directory using the Get ( TemporaryPath ) function. Before I had a chance to troubleshoot this issue I noticed a post in the FileMaker Community titled “FMS 16 breaks CWP” – as a longtime PHP developer with many CWP client solutions this immediately caught my eye!

The post from David Jondreau mentioned that FileMaker Server v16 doesn’t support the Get ( TemporaryPath ) function – sure enough a quick check of the FileMaker v16 help confirms that under FileMaker v16 in “FileMaker WebDirect and Custom Web Publishing, this function is not supported and returns an empty string”. If you compare this to the FileMaker v15 help file it only states that in “In FileMaker WebDirect, this function is not supported and returns an empty string”.

I started troubleshooting my clients solution and after reviewing some server log table records that I had previously setup (always pays to have some kind of server side script logging setup that you can enable/disable on the fly as required) I could see that it was not generating a valid file path as the Get ( TemporaryPath ) function was returning an empty string. Our file paths to insert the image had gone from:




I was able to workaround this by splitting the single script into 2 scripts. The first script is called by the PHP page but it then utilises the Perform Script on Server (PSOS) script to run a script using FileMaker Server to download the file using the Get ( TemporaryPath ) function which is supported under FileMaker Server. The final sequence now looks like this:

  1. download.php file calls the newPerformScriptCommand to run a FileMaker script named ‘Start Image Download’ passing in a number of script parameters
  2. the ‘Start Image Download’ script runs under CWP and as part of this script it also includes a PSOS step to run another script named ‘Download Image’ in turn passing in a number of script parameters
  3. ‘Download Image’ runs as a PSOS successfully

I’ve since downloaded a copy of the FileMaker v16 help file and have been performing some searches to see if I can find any other changes for CWP compatibility. I couldn’t find any reference to these changes in the v16 Custom Web Publishing Guide or other release notes. David has started a new Product Idea in the FileMaker Community as well around this issue to see if some of the functionality can be restored. Hopefully someone from FileMaker Inc. can chime in with an update on why certain changes were made to CWP in v16 and provide a definitive list of what these changes were so we can put in place workarounds for solutions that will be deployed using FileMaker Server v16. If you know of any other CWP related changes in v16 please leave a comment below – I’ll update this post if I find out about any other changes as well.

Update 25 July, 2017: the FileMaker Community forum discussion has been updated with some feedback from FileMaker Inc. on why these changes were made: “Web clients (WebDirect, XML, & PHP) can no longer directly access files that are on the server (DBS) or worker (WPE) host file systems via scripting”. The solution is to use PSOS as described above.