Über Awesome Sauce for FileMaker Server 13

By Andy Frazier

We’re going to take the original default index page on your FileMaker Server 13, and replace it with something a little more interesting, and a lot more useful.

FileMaker Server 13 comes with a page you easily recognize.

It’s certainly functional. In a way. Sort of. I mean it tells you what you have, right? But it doesn’t really help you do anything. So let’s change that. How about this:

And, just to sweeten the deal, let’s make it responsive, so you still get everything you need when you’re looking at it on your phone.

While we’re at it, it sure would be nice to be able get to all the hosted databases right from here, so when we clicked/tapped on “Databases” we’d get a list of, well, databases hosted on this server, and they’d all be “fmp://:” links, so we could just use them to open FileMaker Pro/Go and get right in.

So let’s do that…

1. Get your FileMaker server 13 ready…

Make sure your FileMaker server 13 is set up and running correctly, as outlined in the FileMaker Server 13 Getting Started Guide (https://fmhelp.filemaker.com/docs/13/en/fms13_getting_started.pdf). The home page we’re going to use is built in php, so you’ll want to make sure php is enabled – for simplicity, just go ahead and enable php web publishing when you install FileMaker Server. If FileMaker Server was already installed on a Windows server without enabling PHP, you can refer to the following information on Microsoft’s web site for the appropriate changes in the IIS configuration without reinstalling FileMaker Server:

http://www.microsoft.com/web/downloads/platform.aspx

Simply select PHP from the list of components and continue through the install. Depending on your server OS and whether or not you’re using https, the directory we’ll be working in could vary:

• • Windows (IIS): [drive]:\Program Files\FileMaker\FileMaker Server\HTTPServer\Conf
  • OS X (Apache), using HTTP: /Library/FileMaker Server/HTTPServer/htdocs/
  • OS X (Apache), using HTTPS: /Library/FileMaker Server/HTTPServer/htdocs/httpsRoot/

In that working directory, find the old, boring default file (it’ll be called “index.html”) and rename it (to something like “index_blah.html”)

2. Download This Zip File

3. Put the new files in place

Unzip the files accompanying this article, and put them in that directory. They should include a file called “index.php,” and 3 directories: “js,” “stylesheets,” and “images.” When you’re done with this part, what you should have in there is:

1. • index.php
   • web.config
   • images (directory containing 3 .png files and a .ico file)
   • lib (directory, containing 1 file called “jquery.min.js”)
   • stylesheets (directory, containing 3 .css files)
   • The image that came with the server (that “T” in a blue circle), called “TestPage.png”
   • The index file you renamed in 1.4 above
   • Whatever else was already in there (may include the WebDirect home page, the httpsRoot if you’re using http on OS X, etc.)

4. Test!

Open the FileMaker home page (if you’re on the server, that would just be “localhost” or 127.0.0.1 in your browser). You should see a page which looks like that “Über Awesome Sauce” page above. If you don’t see that…

1. • If you see raw php code (a page that starts with <?php), php is not running on the server – go through the FileMaker server 13 deployment and make sure php is enabled, and just to be safe, install the FM copy of php.
   • If you still see the original default page, there are a few things to check:
     1. Did you update the files in the right place?
     2. Do you have to modify the permissions (Mac: Get Info -> allow “Everyone” to read, Windows: Properties->Security->allow the IUSR read/execute privileges)?
     3. Did you rename the original file (if you didn’t, the server may be configured to give “index.html” a higher priority than “index.php” when both exist – that’s why it’s a lot easier to rename index.html than to reconfigure the server).

Now, you could leave it at that, and everything would work. BUT – you’re a developer and you are just too insatiably curious to leave it there. So let’s break down what’s going on here.

The PHP at the top

<?php
$rawHost = $_SERVER['HTTP_HOST'];
$rawOS = php_uname('a');
$firstWord = strtok($rawOS,' ');
$osName = ($firstWord=='Darwin') ? 'Mac' : 'Windows';
?>

• The first line defines a variable called $rawHost, using the php $_SERVER super global, to identify the server’s address for use in links later.
• The second line uses the php_uname() function to get a bunch of information about the server operating system. This includes the OS version, name, and a variety of other information, depending on the OS.
• The first word returned by that function is something that can be used to identify the OS. This line extracts that word.
• The last line looks at that word, and if that word is “Darwin,” we know the server is a Mac. Otherwise, it’s Windows. This function, of course can identify lots of other operating systems, including Linux, FreeBSD, etc. For this, though, since FMS only runs on Mac & Windows, and Mac always shows up as “Darwin” using this function, we’ll just assume non-Darwin is Windows.

The HTML

This page uses Skeleton (http://www.getskeleton.com), which is a css framework that makes it very easy to build responsive web pages, with a lot of the heavy lifting already done for you. Most of the structures here are documented very well on the framework’s home page, but here are some particulars to notice for this page:

• On line 28, we’re using the name of the OS we grabbed above ($osName) as part of the page title.
• We use it again on line 65, in the subheading.
• On line 72, we’ve got the original graphic from the old index page.
• The links in lines 76 thru 81 use the $rawHost variable defined in the php to echo out the address of the server as it appears to the page visitor.
• Lines 82 and 83 have some very interesting stuff going on to allow the database names to be listed, described below.

The JavaScript

We’re using jQuery in this page, mainly because it’s just too cool. Also it makes doing stuff like what we’re doing here very easy. It’s actually used on more than half the internet, so…if it’s good enough for them, it’s good enough for me!

• On line 92 we load up the jQuery library from the “lib” directory.
• The block starting with line 94 and ending on line 139 is jQuery’s “document ready” function, which basically says “do this stuff when the page has loaded and is ready to execute some JavaScript.”
• Line 95 hides the “div” on line 83, which has an ID of “jsResponse” (as in “JavaScript Response”). You’ll see why in a minute.
• Line 96 adds an unordered list (“ul”) to the last list item (“li” element) on line 82, which has an ID of “dbnames.”
• Line 97 creates a new array, called “dbNames” – we’ll get to that in a sec.
• Lines 99 thru 114 use jQuery’s “ajax()” function to pull in some info from the server and put it in the page…
  • Line 100 specifies that this will be a “GET” request (as opposed to “POST”)
  • Line 101 says we’re getting our info from the built-in fmresultset.xml document, with a parameter of -dbnames, which basically gives us an xml document that lists all the databases on the server (actually, all the OPEN databases which have XML sharing enabled – important to remember that if a database doesn’t show up for you…below, we’ll add in the ones which have WebDirect enabled, but to show up here, one of those 2 sharing methods has to be enabled and the DB has to be open on the server).
  • Line 102 tells the function that we’re getting XML back, so it knows how to read it
  • Line 103 says “do this if the call to that xml page completes successfully”
  • Line 104 is jQuery’s way of finding the “record” element in the returned XML. The fmresultset document returns each database name in an element labeled “data” inside an element labeled “record.” So we have to drill down to it – starting with “record.” This line also specifies that we should repeat this for each “record” we find (using “each”).
  • Once we’re inside a “record” element, on line 105 we look inside it for the text inside the “data” element (which will be the database name), and store that in a variable called “dbName.”
  • Line 106 adds this database name to the array we set up on line 97. More on that in just a minute.
  • Line 107 assembles a new list item (“li”), which includes a link to the “dbName” using the “fmp://“ protocol and the “$rawHost” variable we grabbed above for the server address, and adds it (appends it to) the “jsResponse” div we hid above in line 95.
  • Lines 111 thru 114 say what to do if there’s an error – if the list doesn’t come back OK for whatever reason. Basically, it will add one list item (“li”) to the unordered list we added in line 96, and that list item just says there was an error.
• On line 116 we start another ajax call, this time to get the list of databases that are set up for sharing via WebDirect, in case there are any that we didn’t already catch above What we’re doing here is almost identical to what we did with the XML list above, with a few key differences:
  • FMS includes a built in function (called by going to [server]/fmi/webd/dbnames), which it uses on the default WebDirect home page, that lists the available databases in JSON format. Luckily, jQuery knows how to deal with JSON just as well as it does with XML.
  • What FMS returns in JSON for each database is a key/value pair (like a variable name and the variable’s value). So that’s what we focus on for each returned item in line 121.
  • The key is really all we care about, because that’s the actual name of the database.
• At this point, we check to see if we’ve already listed this file above. We do that using Javascript’s “indexOf()” method, which basically checks to see if an item exists in an array. Remember we added each database above into the dbNames array (in line 106)? This is why we did that…so we wouldn’t end up listing any databases twice. If the indexOf() method returns -1, that means the item isn’t there. So in that case, we do what we did above in line 107 – assemble an “fmp://“ link for this file and add it to the “jsResponse” div.
• After closing the ajax functions, on lines 134 thru 137, we define what happens when someone clicks on the list item on line 82, the one with the id of “dbnames.” We use jQuery’s “click()” function, which listens for user clicks (or taps), and then jQuery’s “toggle()” function, which toggles between showing and hiding an element (the “jsResponse” div in this case, which now contains our list of databases). This is why we hid this element on line 95 – so the list item which displays it would initially appear just as a link that the user could click.

Have fun!!

-Andy Frazier

*This article is provided for free and as-is, use, enjoy, learn, and experiment at your own risk – but have fun! eXcelisys does not offer any free support or free assistance with any of the contents of this blog post. If you would like our help or assistance, please consider retaining eXcelisys’ consulting & development services.

About eXcelisys, Inc.: Founded in 2001, eXcelisys (www.excelisys.com) is an FBA Platinum Partner and FileMaker Certified developer organization. eXcelisys specializes in designing, developing, customizing, supporting, consulting, migrating, upgrading, fixing, and integrating of FileMaker Pro and FileMaker Go database solutions, MySQL, PHP, CodeIgniter, PostgreSQL, QuickBooks-FileMaker Pro Integration, Excel and MS Access to FileMaker Pro conversions/migrations, iPhone and iPad business solutions, and other various database frameworks and web technologies that automate your organization’s data solution needs for use on the web, mobile, and desktop platforms. Contact eXcelisys today for a free estimate and consultation about your business software automation needs @ 866-592-9235.