Triggering a FileMaker Script from PHP - the dreaded -10810 error

First, know that I am a programming neophyte and I have a friend helping with the PHP side (we are both just learning Applescript). Basically, we want an Applescript that is triggered by an action from the PHP code. The script should accomplish two basic tasks: 1) look for a folder by a particular name (the WebKey) in a specific place, delete it if it is there, and then create a folder with the same name in the same place (regardless of whether there was a folder there before), and 2) find the record with the WebKey within FileMaker then run a FileMaker script based on data from the website (in the example below, it should be running a script called “pdf-contract”).

Based on what we learned, we came up with the script below. This script runs fine when we run it from “Applescript Editor”, but when we try to run it from the PHP, we get the dreaded -10810 error:

on run arg
	set fileName to arg's first item
	set pdfScript to "pdf-" & fileName
	set webKey to arg's second item
	set filePath to "Computer:Library:WebServer:mydomain.com:downloads:" & fileName & ":"
	tell application "Finder"
		if exists folder (filePath & webKey) then
			delete folder (filePath & webKey)
		end if
		make new folder at alias filePath with properties {name:webKey}
	end tell
	tell application "FileMaker Pro"
		show database " mydatabase"
		show layout "General Input"
		show (every record whose cell "WEBkey" = webKey)
		do script FileMaker script pdfScript
		show layout "General Input"
		do menu menu item "Hide Window" of menu "Window"
	end tell
end run

Based on what I have read, I carefully went through the troubleshooting steps outlined in the XLab article, but found no evidence of zombie processes, fork bombs, or runaway processes. Beyond that, I cannot find anything to help me in my search.

In trying to troubleshoot the matter, the error occurs in either of the “tell” portions of the script: if we comment out both of these portions of the script, it runs fine from PHP, but as soon as we bring either section back in, that’s when we get the problem. My partner in crime believes it is a permissions issue and he said he set the permissions to “777” but I am not sure where/how he did this.

This is our last hurdle in a major upgrade from a very old server; replacing two old boxes running 10.2 and 10.4 [this box ran FileMaker Server 5.5] with the one new box running 10.6.8 with FMS 10. We introduced the AppleScript step as a way around the limitation that FileMaker introduced of not being able to trigger a FileMaker script with PDF generation in it from PHP code. We actually had this process working, but the solution was accidentally erased by a complete moron size=1[/size], so we know it can be done.

Thank you in advance for any assistance!

Model: Mac Mini
Browser: Safari 534.57.2
Operating System: Mac OS X (10.6)

I have no idea about this, and that error code doesn’t have any explanation.

Got my attention, now, if that AppleScript was saved as an osa script, and executed as a normal shell script from php, then 777 would make sense. My 2 cents.

Bumping up in case anyone has any input. We’re stumped!

Don’t know anything about PHP, but when scripting Filemaker I almost always tell the app, tell the window, and tell the layout, which you can navigate to beforehand if necessary. (Unless the Applescript is being run from a field or script inside the database. If so, do not include the tell app.) The layout needs all the fields referenced to be on it. To run a Filemaker script, I use: do script “Name of script”.

Thanks kerflooey for the input. I am familiar with the FM scripting steps, but we need the Applescript to be triggered from PHP (when people access our web site). FM is actually superfluous to the Applescript issue as even when we remove any FM references within the Applescript, the Applescript still won’t run. I am fairly sure it is a permissions issue (since Apache is not considered a user, it doesn’t have the proper permission to run an Applescript natively. From what I have read, it appears that we can get around it, but thus far, we haven’t figured out the “magic bullet.”