You can still listen to the audio recording of our whole call in the original article Per-Database FileMaker Plug-Ins.

That was in early 2011, about a year after the release of FileMaker Pro 11.

So let’s see what happened in the following releases and how FileMaker listened to our feature requests.

HOnza’s discussion with Mark and Hal originated from the issue that installing plug-ins was not easy to automate, it was hard to find out what plug-ins were installed, and it was difficult to resolve collisions between multiple solutions using different versions of the same plug-in.

About a year later, FileMaker 12 product family was released and I am happy to say that developers using plug-ins were not left alone, as some very interesting changes and features were introduced.

If you didn’t use plug-ins heavily before you may have not noticed them, but for developers using plug-ins on regular basis these changes were huge. So let’s take a look at them in detail.

Installing from container

First of all, the way we automate installing plug-ins was re-designed from the ground up. Originally we had to store plug-ins in a dedicated folder on the FileMaker Server, and use an AutoUpdate plug-in, developed by FileMaker, to install 3rd-party plug-ins. FileMaker 12 replaced the external function with a script step called Install Plug-In File.

You can now simply store the plug-in’s binary in a container field and install it using this script step. One of the side benefits of this approach is that you can automate plug-in installation even in solutions that run locally in FileMaker Pro or FileMaker Runtime without using FileMaker Server.

Version specific Extensions folders

Another change introduced in FileMaker 12 were new folders where FileMaker Pro looks for plug-ins. Since FileMaker 12 brought a lot of changes in general, many plug-ins needed to be updated for FileMaker 12 and some were hard to keep also backwards compatible with FileMaker 11. And because FileMaker 12 also introduced a new file format, it was necessary to find a safe way to have both FileMaker 11 and FileMaker 12 installed on the same computer.

To solve this issue, FileMaker 12 was the first to use a version-specific folders for scripted installation of plug-ins.

Server-side scripting engine

While it was possible to install plug-ins on the FileMaker Server since the version 7 and use plug-ins from within a server-side script since FileMaker Server 9, not many developers were using them because it compromised stability of the whole server significantly.

FileMaker Server 12 introduced a major architectural change, separating the scripting engine completely as a stand-alone process, making it much safer to use plug-ins in server-side scripts. If an unfortunate event of plug-in crash happens in a server-side script it now only crashes the scripting engine but not the database engine.

It is still very important for plug-in developers to write their plug-ins much more carefully for FileMaker Server, of course, but the separate scripting engine finally allowed larger adoption of server-side plug-ins.

FileMaker Server 13 brought another challenge, making the server-side scripting engine fully 64-bit, which requires 64-bit plug-ins to be used on the server.

Installing on server

While installing plug-ins on a client machine was always relatively easy and could be, although not easily, automated, installing or updating server-side plug-ins always required manually putting them to the right folders on the server machine, and carefully setting file system permissions for them.

That’s not truth any more. The new script step Install Plug-In File makes it easier to automate plug-in installation for clients, but you can allow FileMaker Server to use this script step as well.

Checking installed plug-ins

Easiness was not the only thing developers were looking for. Equally important is to make installation and updates of plug-ins safe and properly handle any errors. And the best way to handle a potential error is to avoid it even before it occurs.

With FileMaker 11 or older you could only check what plug-in is available on the server but you relied on each plug-in to be installed and enabled to check whether it is installed and what version is installed.

Starting from FileMaker 12 you can use the new Get(InstalledFMPlugins) function to list all plug-ins that are installed, including disabled plug-ins, and check what version of each plug-in is installed as well. All that before even attempting to install or update any plug-in.

Further improvements with FileMaker 13 thru 17

Although FileMaker 12 was a major step forward for plug-ins, the improvements did not stop there. Every following version release made more things possible. FileMaker’s engineers started to host regular meetings with plug-in vendors at every DevCon to discuss current issues and needs, and these meeting resulted in things like better stability, being able to add custom script steps, and even, finally introduced with FileMaker iOS App SDK, plug-in support for iOS.

So, when you now check what HOnza discussed with Mark Cyrulik and Hal Gumbert back in 2011 and see what features and changes were added since then, do you think FileMaker listened to us and made our dreams come true? And what do you think, what other great news for plug-ins are coming in the next release?