Many FileMaker developers use FMP URL links in order to get FileMaker scripts to run from actions taken in a web viewer. For example, this is how DayBack calendar runs your FileMaker scripts when you edit an event in the calendar.
When FMP URL links are functioning properly, these scripts can update records flawlessly. When they don’t work correctly, they may try to open another copy of FileMaker, or just fail silently. And things that fail silently can be really hard to hunt down.
[ba-box background=”#ffffc7″ border=”#949c9f” textcolor=”#F7F7F7″]
Here’s a great introduction to these URLs if you’re new to them: the FMP URL protocol in FileMaker. But don’t worry, you don’t need to know how these work to use DayBack, ProMaps, or any of the other apps based on web viewers. In fact, when you’re using DayBack and have your script debugger on, DayBack’s FileMaker scripts fire when you’re editing events just as if they were called without a URL.
[/ba-box]
When we were trying to come up with a way to verify that a client’s FMP URL links were working properly, we first came up with the idea to run a script upon opening the file that uses the “Open URL” function. This URL sets a global variable in the file to “true”, which is then checked further in the script to verify that FMP URL links are functioning. If the variable is not set, then the script throws an error.
Here’s our first attempt at seeing if the URL was firing:
Unfortunately, we found that the “Open URL” script step sometimes resulted in the test passing, even when FMP URLs were not functioning properly.
It turns out the “Open URL” script step works just a bit differently than FMP URLs started in the web viewer: the script step almost always targeted the correct version of FileMaker, while the same URL called from the web viewer would not.
It seems the only way to definitively test the functionality of FMP URL links is to start the test from a web viewer or a browser: we opted make a web page available that the user can browse to and click a link to run a script in the file.
You can see our test in DayBack’s documentation here: FMP URLs
One caveat to this method is that the user’s file name must match the filename in the link. This is why we’ve included instructions on copying and pasting the link into their browser’s address bar, customizing the link to their own file name.
FMP URL link issues can be tricky to diagnose. Hopefully, this can be helpful for those of you running into the same issues in your environment.
Update: June 1, 2019. As of FileMaker 18, this gets better. FileMaker introduced version-specific URLs like fmp18://… For more on what that means and how to use them check out FileMaker 18 and FMP URLs.
7 Comments
Why not add the version as a script parameter and then “redirect” it if it isn’t the correct version? fmp://blah.com/?script=version¶m=18
As MrWatson said. Yeah. “Usually works”=”Doesn’t work”. This entirely kills a commercial product I was working on until this evening. I’m not having nontechnical end users install an unsupported third-party System Preference, edit their Windows registry, or engage in any sort of system-level mucking about in order to use a utility that was supposed to make their workday easier. This completely kills my product. Great.
Hi Wilbu,
I’m not going to defend FileMaker’s inability to install the right protocol mapping: FileMaker 17’s URL issue was a serious pain for anyone who’d had an earlier version of FileMaker installed. But this change they made in FM18 does fix it. (The change is described here: https://www.seedcode.com/filemaker-18-fmp-urls/)
If your customers are using FM18, you can now use the fmp18:// protocol and those URLs will open FM18. (And when 19 ships, the calcs shown in the link above will switch to fmp19:// if that’s what your users have.) So I don’t know if “completely kills” is totally accurate–at least I hope not. As of FileMaker 18, the URLs not working is now only a possibility when two things are in place:
1) the customer had a previous version of FileMaker installed on their machine, and
2) they’re now using FM17 OR they’re using FM18 and your app is asking for fmp:// instead of fmp18://
I hope that’s good (better?) news.
– John
Just never use any technology which works only “almost always” ! Databases need to be based on technologies which work “always always”!
The calling of a FMP-url in a webviewer opening the wrong version happens to me, which then requires me to work in only one version of FileMaker at a time. Not usually a problem, but it did get in the way at times.
I don’t know of a good way around that, but would be interested to know.
Having it work in whatever (one) version you have open is currently the best experience available. I believe we’d need FMI to make the url version specific to let multiple copies run at the same time.
Hi John,
Specific to OS X:
I wonder if you might be able to share any insight on how to fix the situation where invoking the FMP URL results in the OS attempting to launch an *older* version of FMP which is not presently running. I some research into the lsregister CLI tool to attempt to unregister older versions of FMP, and also ensure that the desired version was registered. This helped, but does not seem to be a true long term solution, since, if a user ever launches the older version of FMP, it will re-register itself, and result in the same behavior mentioned above, i.e. the OS will attempt to use the older version even if it is not currently running. Specifically I am dealing with a situation where using FMP URLs in v.15 results in the OS launching v.14.. This only happens on some users’ systems. I am stumped. Any thoughts? Thank you very much & kindest regards, -steve