Goya Blog

You can run FileMaker Server on Mac OS X or Windows, but not Linux. But you can have a Linux based web server accessing either OS and it is quite simple to setup and run. The bonus is that because you're following a standard FileMaker Server install it should still be a supported configuration.

To start with, choose your FileMaker Server OS, and install FMS as a Single Server option. You can then use firewalls if required to block this machine from unwanted access. You still need a web server on this box, so in our case this is IIS, but it's firewalled off from public access and limited to access only from our Linux Web Server.

We chose Ubuntu 10 for our Linux box. Anyone with some Linux experience could replicate these steps on other platforms though.

The FileMaker API

First get a copy of the FileMaker API files, they're already provided in the FileMaker Server install at :

FileMaker Server\Web Publishing\FM_API_for_PHP_Standalone.zip

Take these zip files and move them to the Linux box, and unpack them somewhere that's NOT in the web root folder, for example in :

/home/myname/FileMaker

You then need to add this folder into the php.ini file, in the include_path option. So our new include_path was now :

include_path = '.:/home/myname/FileMaker:/usr/share/php:/usr/share/pear'

Also our default PHP install needs a couple of extra packages to work. PEAR Date.php and curl are required, so install those:

apt-get install php-date
apt-get install php5-curl

Finally edit the conf files inside the unpacked API to point to the actual FMS host. This file is located at :

FileMaker/conf/filemaker-api.php

in whatever folder you unzipped the API files previously. There is an option in there for $__FM_CONFIG['hostspec']. You need to change the hostspec setting to be the IP or domain name of the FMS box.

And finally restart Apache and you should be all good to go.

Troubleshooting

If it's not working, check your firewalls. The two web servers ( Apache on Linux and IIS on Windows ) need to be talking to each other via port 80. Also, check the web and PHP logs on both machines for other clues or issues.

Using IWP

This works perfectly well with Instant Web Publishing as well. You need to add another step whereby you use a Reverse Proxy to direct just those urls to the internal FileMaker Server address. So this would be something like :

ProxyPass /fmi/iwp/ http://your.fms.domain/fmi/iwp/
ProxyPassReverse /fmi/iwp/ http://your.fms.domain/fmi/iwp/

This can go in your .htaccess file if you're using those or in a VirtualHost section for multiple domains as well.

Hot on the heels of yesterdays Big RefreshFM update is another smaller RefreshFM update. This one bumps the version number to 1.1.6 and has two minor fixes :

Firstly the portal listing old file names is now editable, so you can modify file names directly there, or add in new files.

Secondly if you had a setup where you had multiple files, or filenames between old and new that weren't the same, it was possible that the copy old file step would copy files with the wrong name. This has been fixed.

As usual, downloads are available, and you can import from a previous version ( from 1.1.3 onwards ) into this release using the "Import" button when RefreshFM opens for the first time.

There is a feature in BaseElements where you can access any Analysis from any other solution by calling a script inside BaseElements. This is a neat feature for those people who use other FileMaker based project management tools and allows you to build a link into BaseElements for the current analysis of your FileMaker solution.

But there is also the ability to access the data tables inside the BaseElements_Data file, which means you could build your own UI using the BaseElements data and access it any way you want. This could be really neat for managing your solutions, but there is no way to link to the correct layout in the BaseElements UI file for any record that you're viewing the data for.

BaseElements 3.0.11 adds a new feature where there is a script you can call with layout and field details, and BaseElements will go to that layout and perform the find for you. This effectively gives you the ability to link to records in the UI file which you otherwise would not have. The actual data tables are all in the Data file, so a GTRR will let you go there, but there's nothing useful to see.

To get this working, there is a script in the main BaseElements file called "External: Go to Related Records" which you can call with parameters to set which layout to go to and which fields to search, along with which values to find in those fields. This script is modifiable, so you can see for yourself what it does, and make changes if required. The bonus is that it won't be changed in future releases, so you can call this script from other files and it will remain the same.

The parameters are a list of values you want to use. The first item is the layout name. All of the remaining values are in name-value-pair format according to our previously published examples. So for example, to go to the layout called "MyReport" and search for "abc" in the field called "widgetname", you would use the following as your parameter :

MyReport
widgetname="abc"

I've attached here a sample file containing scripts that do this for you, along with examples of Custom Functions we're using to set and retrieve these name value pairs.

A long time ago ( in internet years ) Digital Fusion published their method of using an installer to update FileMaker plugins. This was part of Craig Saunders presentation at the FileMaker Developer Conference 2010 in San Diego.

Although I've previously published methods for updating plugins via FileMaker Server, I've been meaning to look at the Digital Fusion method for a while, and build a sample file for doing this using our new free open source BaseElements plugin.

Well I finally had a concrete need for an plugin update mechanism in RefreshFM and because RefreshFM doesn't work on the server, it needed to be all local. As well, with the distribution version of RefreshFM is going to be in use by users who may know nothing of plugins it needed to be as simple as possible. So the idea of using this installer method really appealed to me.

Tweaks

I made a couple of changes to the process that Craig and Stephen outlined in their sample files.

Firstly, on windows, I elected to use InnoSetup instead of Install Creator. InnoSetup is free and has all of the features I needed, and I was already familiar with using it on other projects. But in theory you could use any installer builder software.

Secondly, on the Mac, the DF guys are exporting an XML plist file to do version comparisons with. I considered this overkill for what I wanted, and I was happy with just using the ability to check this detail inside FileMaker and then installing as required. This gives you a little more flexibility with where you install and also made the actual options in the installer simpler.

And finally, I also wanted the ability to re-open the database that you'd started with. I was sure from the demo or what I'd seen before that this was included with the demo materials, but I couldn't find it and the online demo files didn't show this ( or at least as far as I could see ). So I added some code to the post install scripts to open the RefreshFM file after the install is complete. It is mentioned in their slideshow from the DevCons session as an option for windows, so I assume they've at least considered it on the mac too.

Demo Files

The attached demo files contain a working copy of everything I've included in RefreshFM. There is the main PluginUpdates.fp7 file which contains a copy of the installers as well as the code to export and open them.

The .pmdoc file is the PackageMaker file. You need to download Apple's Developer tools to get access to this. XCode is available on the App Store, and is also available for people who have developer accounts with Apple.

The .iss file is the installer setup file on Windows, you need a copy of InnoSetup to open this, but it's free software.

Mac Installer Bug

There is a bug with the installer on the mac, where the settings I've used default to the User's Library folder. So when the installer comes up, there is only one choice ( Install for current user ) which appears to be selected ( it's got a blue highlight ) but the continue button is greyed out. You need to click on the "Install for current user" option to make it active ( which doesn't change the highlight ), and then the continue button becomes active and everything works.

I've left this as is in my sample files, so the issue is still present. The DF guys have got a workaround in their version of the installer, where they install to the temp folder, but into a link that points to the actual user's folder. So the installer doesn't present the dodgy dialog. However, that option requires Administrator privileges, which not all users will have.

I'm not sure that either solution is perfect, and I've spent a lot of time fiddling with settings or options in the installer to try to alleviate the issue, to no avail. If you have a perfect solution, I'd love to hear about it.

Caveats

And what solution wouldn't exist without caveats : Currently there is no way within FileMaker Pro that I'm aware of to systematically enable a plugin that is inactive. So if the user has the plugin installed, but inactive, this process will update it and leave it inactive, so it will essentially fail. I think this it is reasonable to assume that those using this process will not be making plugins inactive, but it needs to be noted that this is an issue.

Thanks

Thanks to Craig and Stephen for putting the work into this idea originally, and hopefully someone will find my minor additions and alterations useful.