Yuck, this air! We've just opened our windows for the first time in over a week because the air quality is ONLY "Unhealthy for Sensitive Groups".
I built this database back in November 2018 when the Camp Fire was raging in Northern California and the air quality here in San Francisco was getting really bad. Little did I know at the time that I'd be opening this database again every year!
I’ve been using it again the past month, and when I saw how horrific the air is today in Portland OR, I thought I’d send it to a couple Oregonian friends — and then I thought others might appreciate it too. So here you are, Others.
It's basic, but it works. I find it easier to update here than to check the website(s), plus I can see the history.
When the fires started again this year, I learned about PurpleAir, so I added in a way to capture the three PurpleAir monitors closest to my home. The original data, and left column, is from AirNow.
.
To use it:
First, download the file. Then:
a) Find your local AirNow feed at feeds.airnowapi.org
b) Select the link for the RSS “Current Air Quality”
c) Paste this link into the Insert from URL step in the “Get AirNow AQI” script
d) Find your local PurpleAir monitors at purpleair.com/map
e) Click on one of the monitors and copy the ID from the URL. It’s the number right after “select=” (it’ll be something like …&select=5776#… ).
f) Place/paste the number (e.g. 5776) into the repeating field gPurpleAirID_reps on the “all fields” layout
g) Repeat for other local monitors. (I’m only using 3 of the 10 repetitions. If you use more, you’ll need to add them to the layout.)
NOTE: Initially I was just capturing data from AirNow which only gets updated hourly, so the update process only updates when there’s a new AirNow reading, but you can run the PurpleAir update script individually on any particular record too.
And there’s plenty more you clever FileMaker developers could do with it.
With some last-minute volunteering at this year’s CWP User Group at FileMaker DevCon (our 13th annual!), we had a record-high seven people share with the group.*
We saw:
Joel Shapiro @jsfmp (that's me) - details below…
Mark DeNyse @mdenyse, who demonstrated how, with his fmPDA, you can change just one line of legacy FX.php code to use the FileMaker Data API with a new FX.php DataSource class. He then showed techniques for using the Data API to store data passed to a SmartThings webhook, and also demonstrated how to pull weather data from multiple sources (Ambient and Weather Underground) with cURL and the Data API to display in an iOS SDK app.
Charles Delfs @mrdelfs, who talked about how they incorporate testing at four levels in their CWP service. He demoed UX pre-build testing, automated CWP testing, and FMP testing, using fullstory and UI-licious.
Steve Winter @steveWinterNZ, who showed us how he uses database abstraction to decouple an app from its underlying database. Using Doctrine and Symfony he demoed how he can change one line of code to switch between the FileMaker PHP API and the Data API, or potentially any other database connection. You can see his slides and resources on his blog
Mike Beargie @MikeBeargie, who showed us some work he's been doing with Laravel Nova.
David Nahodyl @bluefeathergrp, who showed off a clever mapping solution where they’re caching data as JSON in Amazon S3 instead of pulling it directly from the FileMaker database in order to both improve performance and reduce Data API usage. You can see the demo, using customer/customer as the username and password.
Lui de La Parra @lui_dog, who shared his fms-api-client and node-red-contrib-filemaker, along with Node-RED. “fms-api-client” is a FileMaker Data API client designed to allow easier interaction with a FileMaker database from a web environment. This client abstracts the FileMaker 17 & 18 Data API into class based methods. “node-red-contrib-filemaker” uses “fms-api-client” to connect via the FileMaker Data API to FileMaker Server and provide FileMaker nodes to Node-RED. Node-RED is a programming tool for wiring together hardware devices, APIs and online services in new and interesting ways. It provides a browser-based editor that makes it easy to wire together flows using the wide range of nodes in the palette that can be deployed to its runtime in a single-click.
My turn…
I started out mentioning a couple recent items that all CWP developers should be aware of:
FileMaker Server 17.0.3+ now installs PHP 7, but the PHP API isn’t compatible
For the first time since the FileMaker PHP API came out with FileMaker 9, the FMS installer now installs PHP 7.x. Unfortunately, the API itself has not been updated to be PHP 7-compatible. If you haven’t already updated your version of PHP to 7.x, the easiest way to have your CWP site work with PHP 7 is to use Steve Winter’s PHP API modification. It’s a simple switch of the original FileMaker.php file and FileMaker directory to the same-named versions in Steve’s download.
Note: You may separately need to modify your own PHP code to be PHP 7-compatible
Changes to Java in FileMaker Server 17.0.3+
Due to changes in Oracle’s licensing of Java 8, using the Web Publishing Engine (WPE) for either the XML/PHP API or WebDirect in FileMaker Server 17 and 18 now requires us to either purchase an Oracle Java SE Subscription or use a free open source license of Java 8 (OpenJDK 8). Note: The Data API does not use the WPE and so is not impacted by this change.
Mike Duncan @SoliantMike has written a blog post that nicely describes how to deal with the change.
Who’s using the Data API in production CWP sites?
I then took a brief poll, for my own curiosity, to see how many people are using the Data API in their CWP sites. Very unscientifically… lots of people are(!) Some reported using fmPDA, some fmREST, and some RESTfm which now supports the Data API (yes, there’s fmREST & RESTfm). Presumably other people are connecting to the API in other ways, but they weren’t sharin’ :-P.
Scrollbars made visible on Mac and iOS — via CSS!
I’ve long been frustrated by the macOS/OS X and iOS default setting that hides scrollbars except when actively scrolling. I think this is Bad UX, as users often won’t realize that there’s more content for them to see. Fortunately, scrollbars can now easily be added using CSS (hurrah!) Technically, the CSS specification is about styling the scrollbar—which on Windows (where scrollbars always display) means you can make them look nicer—but to me the best part is that we can now make scrollbars always visible on Mac/iOS.
See the Pen xxKRgEB by joelshapiro (@joelshapiro) on CodePen.
According to Can I Use, browser support is now good (with the inclusion of the pseudo-elements). Even with no/limited support in Edge & IE, Windows users still get the default scrollbars; they’re just not styled.
Quick tip: Emmet plugin
Just a quick mention of the handy Emmet plugin that can be added to many text editors and IDEs. It’s installed by default in VS Code (my editor of choice).
Emmet takes the snippets idea to a whole new level: you can type CSS-like expressions that can be dynamically parsed, and produce output depending on what you type in the abbreviation. Emmet is developed and optimised for web-developers whose workflow depends on HTML/XML and CSS, but can be used with programming languages too.
*It really was great to have so many eager presenters, especially since just the day before I thought there’d only be three besides myself and we might end early. My request for you all is: Please consider sharing something with the group at next year's #ClarisEngage… but puh-leeze let me know in advance so I can plan (sleep) better.
I generally get notified about our room in the Spring and then I tweet about it and post about it in the FM Community. Please let me know you'd like to share as soon as you can after that. Thanks! :-)
FileMaker to Tableau via Dropbox - with no Data API (& free for non-profits!)
First, did you know that Tableau Desktop is free for qualifying non-profit agencies?? 👍
A non-profit client of mine wanted to have a better way of looking at all their FileMaker data. Tableau seemed like a good fit, and thanks to the the free licenses for non-profits, we were able to make this happen.
For a few reasons*, we couldn’t use the FileMaker Data API and the Tableau Web Data Connector. Instead, I set up a system to:
Export the data out of FileMaker
Upload the data to Dropbox, using the Dropbox API
Use these Dropbox files as the data source in Tableau
By running the script nightly as a FileMaker Server Scheduled Script, they’ve always got up-to-date data in Tableau. If they ever need up-to-the-minute data, they can run the same FileMaker script as-needed in FileMaker Pro.
Below are the steps needed to use the included demo file to get data onto Dropbox and to access it via Tableau. You will also be able to place this FileMaker script into your own solutions by customizing the designated script steps to your environment.
Step 1: Set up DropBox
You’ll need to have your Dropbox account set up for using their API. If you don’t have that done already, read on…
(A) Go to https://www.dropbox.com/developers/ and click the “Create apps” button.
(B) Select Dropbox API, App folder, and then Name your app (Dropbox calls each instance of their API use an “app”). Then click “Create app”.
(C) Click the “Generate” button under “Generated access token”.
(D) Copy this access token and so you can paste it into the FileMaker script.
Step 2: Get your data from FileMaker onto Dropbox
(A) Download the FileMaker demo file for exporting data to Dropbox.
(B) Open the FileMaker script “Export-and-Upload-to-Dropbox” in the demo and paste your Dropbox API token into the Insert Text script step (replacing ABCDEFGHIJKLMNOPQRSTUVWXYZ in the demo).
Note: By using the “Insert Text” script step — instead of “Set Variable” — to set the $curl parameters, we don’t need to escape as many of the quotes required in the cURL ("\"")
This should be all you need to do to get the demo file working with Dropbox (and then Tableau, see below).
To use this FileMaker script in your own files, change all of the script steps that are flagged with breakpoints (blue line numbers).
Step 3: Set up Tableau
Open Tableau Desktop and in the left-side Connect menu, select Dropbox
This should open up a Dropbox authentication page in your web browser. Click “Allow” and then go back to Tableau
In Tableau, navigate to the new Dropbox folder you just created inside the Apps folder and select one of the files. Click “Connect”.
You should see the data in that first file. Then click “Add” in the top left, and again select Dropbox
Again click “Allow” in the Dropbox authentication web page.
Back in Tableau, navigate again to your new folder and Connect to the next file.
Once the next file has been added, click the join icon and select the appropriate ID fields in each file.
Repeat for any additional files.
Then click the “Sheet 1″ tab in the lower left.
Start dragging fields into the Columns and Rows. You should see the FileMaker data appear in the worksheet(!)
There’s a LOT to learn with Tableau, and that’s not what this post is about.
For just one example (with the sample data in the demo file):
After dragging InteractionType into the Columns area and Name into the Rows, drag the “Number of Records” from the bottom left (under “Measures”) into the “Marks” card and then make sure that “Text” is selected from the drop-down next to the SUM. Now you should see the sums of each InteractionType per Client.
Moving forward…
The only other thing you should need to do with Dropbox is set permissions for who can access the files. If you make them accessible only to specific Dropbox users, then each time they open their Tableau file they’ll be brought to one Dropbox authentication web page for each file (e.g. two in the demo).
You can run your FileMaker script whenever you want to update the files on Dropbox, including adding it to a Scheduled Script on FileMaker Server.
I hope this is helpful to others, including other non-profits. My client is very happy with this solution.
*We weren’t able to use the FileMaker Data API in this situation because (a) some people needing Tableau access don’t have access to the FileMaker Server (firewalls, etc.), and (b) the client is still on FileMaker Server 16.
On Aug. 6, 2018, we had the 12th annual CWP User Group at FileMaker DevCon. The room was far away from most everything else DevCon (hotel staff call it “walking to China and back”) but it filled up and we had to get more chairs brought in :-)
Presenters:
This year five people shared:
Joel Shapiro @jsfmp (i.e. me) - details below…
Steve Winter @steveWinterNZ urged us to keep up on our developer skills and practices. He’s put together a blog post about it, with a link to his slides “Steve’s top ten tips to being a better developer”.
He’s also got a link there to his PHP 7.x-compatible modified version of the FileMaker PHP API.
Mark DeNyse @mdenyse showed how easy it is to use his fmPDA PHP class to switch an existing CWP site from the PHP API to the new Data API. Just three steps:
1) Swap out include for FileMaker class to fmPDA class
2) Change all $fm = new FileMaker(…) to $fm = new fmPDA(…)
3) Change all FileMaker::IsError($result) to fmGetIsError($result)
Charles Delfs @mrdelfs showed us “A modern approach to web publishing FileMaker, from mobile apps to full company portals”.
Mike Beargie @FMCommunityLive shared a Laravel framework web app he created (in his free time, while teaching himself Laravel & Vue.js) that dynamically connects to FileMaker data sources for purposes of running data processing jobs.
Please contact any of them directly for more information.
CWP and the new Data API
I started by pointing people to Data API / Admin API Packages/Wrappers For FM 17+, a document that Mark DeNyse put up on the FileMaker Community. It lists available packages/wrappers for use with the new Data API, four of which are PHP classes (for using PHP to access data via the Data API).
I then asked if anyone had any real-world information on data transfer amounts and costs, and whether the 24 GB per licensed user per year would end up costing significantly more than XML/PHP-API-based sites, but unfortunately it’s too early to really tell.
Two Quickies:
1) Visual Studio Code has built in UI for Git control, which I’ve found very user-friendly. I'd used Git Tower for years, but now can do pretty much everything right within my editor.
2) There are extensions/plugins for editors that color-code matching brackets, parentheses, etc., which can be especially helpful with nested brackets.
Bracket Pair Colorizer for VS Code
bracket-colorizer for Atom
rainbowth for Sublime Text
CSS Grid
Then I shared what I’ve recently been learning about CSS Grid. I really like how easy it makes web layout, especially when compared to the float-based layouts & frameworks (incl. Bootstrap) that we’ve been using pretty much since Responsive Web Design came around. In fact, Grid features like repeat, auto-fit & minmax can allow layouts to be automatically responsive, without the need for any media queries!
It’s ready to use now
According to caniuse.com, almost 85% of people globally use browsers that support Grid. Four of the main browsers all shipped Grid within the same month (March 2017), and two more shipped within that same year. This is unprecedented in CSS. All browser vendors agreed to a single version and released it “finished”, with no vendor prefixes. The main holdout is IE, which uses an older spec of Grid along with the -ms-* prefix. The current spec for Grid will not change, so we can feel comfortable using it now. (Of course if you know that much of your audience uses IE or older browsers, you might want to wait.)
By using a @supports feature query (similar to an IF clause in CSS), we can have basic non-Grid code in our CSS and then explicitly place Grid-based code inside the feature query:
// simplified layout for older browsers @supports ( display: grid ) { // code for newer browsers // including overrides }
This also makes it real easy to see how your page will look in a non-supporting browser: just change display: grid to something like display: XXgrid —since no browser supports “XXgrid”—so nothing inside your Grid feature query will be used by the browser.
Named Areas
As I was teaching myself Grid, one thing that blew me away was that you can create named “areas” in your CSS (grid-template-areas) to lay out your page or page component. It felt kinda like drawing with CSS code. I first tried a modified example from the scrimba tutorials (below):
See the Pen QBRENW by joelshapiro (@joelshapiro) on CodePen.
Then to play around with it a bit more, I tried something else:
See the Pen VBNKMe by joelshapiro (@joelshapiro) on CodePen.
This was just a quick experiment. I know it doesn’t display as intended in all browsers but I didn’t take the time to try and fix it. This is how I’d meant it to look:
(yes, a CSS-Grid poop emoji 💩)
Grid Lines
Even though these named areas are really fun, there’s a lot of power using the lines in Grid. A two-column grid, for example, has three lines (the two lines at either side of the grid and the one line between the columns). Lines can be targeted by their numbers (incl. negative numbers for right-to-left or bottom-to-top), as well as by names (e.g. main-start, main-end).
DevTools
Currently, the Firefox DevTools are the best for working with Grid. You can easily view a grid’s line numbers, area names, etc. in their Page Inspector.
Resources
I showed a few other examples of what Grid can do, but you might as well check out the tutorials directly.
Resources that I found especially helpful are:
scrimba.com/g/gR8PTE “Learn CSS Grid for free”
Scrimba is a very cool new learning platform that shows video alongside an editor, and you can edit while the video is playing, which pauses the video.
youtube.com/layoutland and labs.jensimmons.com by Jen Simmons
In these videos Jen explains really clearly how Grid (& some other new CSS) works. Her “labs” website has a lot of great examples that you can play with.
CSSGrid.io by Wes Bos
This is a free 25-video course sponsored by Mozilla Firefox.
Happy Gridding!
And please think about sharing something at the group next year! Just let me know!
There was a tweet a little while ago about getting sparklines* into FileMaker with just a font. A reply to the tweet stated that to really be useful we'd need to install the font on client machines. Good point.
I saw that the font was open-sourced and hosted on GitHub, so I wondered if we could use the RawGit CDN to use it as a web font** in FileMaker web viewers, so there’d be no installation necessary...
...and we can!
Caveats
Users must have an internet connection since this is a web font.
RawGit has no uptime or support guarantees so this should not be used for mission-critical solutions.
Product Support
In my testing, this works successfully in:
FileMaker Pro on Mac
FileMaker Pro on Windows
FileMaker Go
WebDirect on Mac (tested on Mac FMServer)
WebDirect on Windows: Chrome only (tested on Mac FMServer)
Custom Web Publishing (as with any web font)
I did not get this to work in WebDirect in Edge or IE on Windows (Mac FMServer) but I didn't try to troubleshoot it. I leave that to you — and please reply below if you find a fix! :-)
The version of FileMaker shouldn't matter, although the OS version might, since web viewers use the browser engine that's native to the OS.
The demo
Download the demo (no email registration necessary!)
I've put comments in the FileMaker file. Basically, we need to define the @font-face(s) in the CSS, linking to the hosted version of each font you'll need. In my testing, Mac needs only the .woff version of the font and an abbreviated grammar of the CSS, but Windows needs more. Instead of trial-and-error-ing until I found the right combination, I just used the full code from the example from the font’s creator. If your solution is cross-platform, use the full code since it works on both.
Usage
The values in the sparkline need to be whole numbers from 0 to 100 and must be nested between curly braces { } , separated only by commas. Lucky for us, FileMaker gives us plenty of ways to compile our data into this structure.
The values then need to be placed inside an HTML element that has the appropriate CSS class attached. Inside that element you can also place the first and last values—on either side of the curly braces—which will be output in the sparkline font (instead of any other font you might be using in that web viewer).
*Sparklines were developed by Edward Tufte (yay!), who described them thusly:
A sparkline is a small intense, simple, word-sized graphic with typographic resolution. Sparklines mean that graphics are no longer cartoonish special occasions with captions and boxes, but rather sparkline graphics can be everywhere a word or number can be: embedded in a sentence, table, headline, map, spreadsheet, graphic. Data graphics should have the resolution of typography.
- Edward Tufte, Beautiful Evidence, 46-63. (scroll down)
And you can find lots more uses and examples of sparklines around the Internet.
About web fonts
**Web fonts:
Web fonts allow Web designers to use fonts that are not installed on the viewer's computer.
A Bookmarklet to restore FileMaker WebDirect Toolbar buttons in Chrome 62+
UPDATE: Google Chrome 63 was released on Dec. 6 and this problem is now fixed :-)
Google Chrome 62 was released on Oct. 17, 2017. With it came a situation on some (older?) Macs running El Capitan (OS X 10.11) in which the buttons in the FileMaker WebDirect Toolbar do not appear, even though they still function. UPDATE: FileMaker’s Testing department has been able to reproduce this also in Sierra & High Sierra (macOS 10.12.6 & 10.13), although I haven’t seen that. (link)
I've created a bookmarklet that should restore the button images.
How to create the bookmarklet:
a) Copy the JavaScript code (below)
b) Right-click (or hold the “option” key and click) on your Bookmarks Bar in Chrome
c) Select “Add Page…”
d) Enter a Name for this bookmarklet
e) In the URL field paste in the JavaScript
f) Click “Save"
g) Log into your WebDirect solution and then click your new bookmarklet.
(gone are the days when you could just drag a bookmarklet onto your bookmark bar :( )
FWIW: The issue seems to be connected to CSS, so the bookmarklet injects some CSS (via JavaScript) so that the buttons are visible again. For whatever reason, the elements that hold the buttons have something weird going on with their background CSS. Using background-clip: content-box; seemed to be the simplest fix, even if it’s not exactly changing the root cause of the problem.
You can see more about the issue and follow for updates at: WebDirect Toolbar buttons no longer display in new Chrome 62 on El Capitan on FileMaker Community.
(The bookmarklet was modified from this one. It might not be the most efficient, but it works ;) )
This year was the 11th Annual CWP User Group at FileMaker DevCon. We had a full house,
although unfortunately the room was long and narrow, so people in the back couldn't see the small screen very well. Please include a comment about the room when you rate the meeting via DevCon2Go or the web page.
Once again we had five people come up and share with the group.
(Please consider sharing something next year! Just let me know (early enough) and I'll block out a slot for you!)
Joel Shapiro @jsfmp (yours truly) - details below…
Steve Winter @steveWinterNZ talked about a Doctrine driver that's used for DB abstraction with things like Laravel & Symphony:
https://msdev.co.uk/filemaker-cwp-symfony-doctrine
Mark DeNyse @mdenyse showed some of an iOS app that he built with the FileMaker iOS SDK that communicates with FileMaker Server only via CWP.
Ken d’Oronzio @kdoronzio showed us the "fmREST" PHP class that he's created for working with the Data API through PHP. It's FREE :) and available at:
https://www.sosimplesoftware.com/fmrest.php
Gjermund Thorsen ggt667 gave us a taste of his CRUUx for CRUD - a mixture of FM DATA API, CWP, and REST API:
here and here
In case you couldn't tell, I'm not much of a note-taker, so if you want more details from any of the other presenters, please contact them directly ;-)
My turn…
I started by sharing the sad news that longtime FileMaker and Web developer, Tim 'Webko' Booth, died of cancer on July 2. He was 46 years old. He'd actually been planning on coming to this year's DevCon for his first time after working with FileMaker for 20 years, but in April he wrote to the FX.php list that he'd been diagnosed with kidney cancer. He'd been very active on a number of FileMaker and web lists and forums, for many many years. I was able to find — in an archive of the old usenet comp.databases.filemaker — an interaction I'd had with Webko in 2000 (17 yrs ago!) in which he'd helped me with some CDML, and I know that many other CWP developers had similar experiences. It's a big loss to the FileMaker/CWP community, as well as of course to his family and friends back in Australia.
Cross-browser testing
I then talked briefly about doing cross-browser testing through sites like BrowserStack and CrossBrowserTesting, and how you can use CrossBrowserTesting for FREE for small(-ish) components of your websites if you put those parts into a "pen" on CodePen — as long as you have an account on each site (free accounts are fine). I use this for testing things like new animations or components that I know may not be fully compatible with older browsers or OSes. And did I mention it’s FREE?
File sync
Next, I showed a quick demo of my favorite file-sync tool: Forklift. I use git (via Git Tower) for file versioning, but for syncing my development sites up to my clients' production servers, I use Forklift to create what it calls "synclets". These are little apps that perform each sync… without Forklift having to be open! Just have the remote directory open on your computer (e.g. via “Connect to Server…”) and double-click the synclet. As simple as that!
NOTE: This is with Forklift 2. Forklift 3 has just come out and it has a similar, if differently named, feature.
So, if you don’t love the way you currently do file sync, you might want to check out Forklift.
What’s the future of CWP (XML & PHP)?
After this we looked at the current state of CWP, specifically XML- and PHP-based CWP. As we all know, FileMaker Inc. is now pushing their new Data API as "the way to go"* for connecting to FileMaker Server. Of course it's still in beta through Sept. 2018 and we don't yet know how they'll price its use (which makes it pretty difficult for us to plan new projects), but the days of XML- & PHP-based CWP are clearly numbered. In fact, I was surprised by how many people throughout DevCon, including one of the top engineers at FMI, believed that CWP is already deprecated, even though it officially is not.
*At the "Under the Hood: FileMaker Data API" session, someone in the audience innocently asked what the advantages are of using the Data API instead of PHP/XML in the example they’d demoed, especially since the code shown was quite complex, using Node.js and pug.js. When he didn't get a straightforward answer, he asked if it was perhaps because the Data API was faster. One of the presenters responded that it was because "the Data API is the way to go"(!)
Changes to CWP support with FM 16
I pointed out a recent discovery that FM 16 has dropped CWP support for Get (TemporaryPath) & Send Mail [with Attachments]. These weren't announced in any release notes although they were noted in the Help docs. Fortunately, Andrew Duncan found that you can use PSOS to regain access via CWP.
As a follow-up, FMI has since clarified that this new incompatibility is due to changes made to FMS 16: “Web clients (WebDirect, XML, & PHP) and FM Data API calls can no longer directly access files that are on the server (DBS) or worker (WPE) host file systems via scripting.”
Our options…
I then showed this table of the current options we have for doing CWP:
The first five options — FileMaker PHP API, FX.php, RESTfm, fmxj.js and the new FM PHP API “rewrite” (see below) — are all dependent upon the survival of the XML Web Publishing Engine. When that goes away, all sites using any of these options will either need to change to the Data API or stop upgrading FMServer once the XML WPE is dropped.
Support for PHP 7.x
Separate from the issue of how long we’ll be able to use the current WPE, the FM PHP API cannot be used with PHP higher than 5.6, so for anyone needing to use a more-recent version of PHP, we need an alternative. Two months ago, Romain Dunand (@airmoi) of 1-more-thing released a “rewrite” of the FM PHP API on github (which they blogged about at “No, the FileMaker API-PHP is not dead!”). When I found out about this, I wanted to see how easy it would be to switch a site from the FM API to this new rewrite. I was happy how smooth the transition was and so I did a demo for the group (details below).
As soon as I finished the demo, two other options came out. Our own Steve Winter told us that he’s modified FileMaker.php to support PHP 7.x and he’s made it available at: https://github.com/matatirosolutions/filemakerapi. All you’d need to do is swap out his modified file with the original FileMaker.php file and you’ll be compatible with PHP 7.x. (Someone else commented that there’s a command-line change he’d made to make the FM API compatible with PHP 7.x, but he didn’t have a reference to give us.)
The FileMaker PHP API Rewrite
Romain’s rewrite has a number of features that are not in the original API (all listed on its github page), such as new error-handling, but what had most interested me was its support for PHP 7.x and seeing how easy it was to switch an existing site from the FM API.
First, you need to place the rewrite folder on your web server (I named it “api-rewrite”) and then, instead of calling 'FileMaker.php' you call 'api-rewrite/autoloader.php'.
You’ll then need to add:
$fm->setProperty('errorHandling', 'default')
(unless you want to change all your existing calls to the API).
And then you need to place these two lines onto every page that calls FileMaker:
use airmoi\FileMaker\FileMaker;
use airmoi\FileMaker\FileMakerException;
which namespaces the FM API within the rewrite.
With those few changes, your site will now work fine on PHP 7.x.
Or, as noted above, if all you need to do is make your FM API site compatible on PHP 7.x, you could just replace the original FileMaker.php with the one that Steve has modified.
My 15 minutes…
Well, that pretty much took up my time at the group…
But for anyone who couldn't read the screen during my intro, when I shared that I'd won Second Place(!) in a national magazine's weekly contest just three days before our meeting, here are the details on that:
The Week magazine has a contest every week. On July 21, 2017, they announced the winners of the previous week’s contest. I won Second Place (ahem):
The Question: “A report from a national veterinary chain revealed that one in three American house pets is obese because of lack of exercise, overfeeding, and owners who "use treats as a form of communication." If an entrepreneur were to launch a Weight Watchers-style program for pets, what could it be called?”
SECOND PLACE: “Rovereaters Anonymous”
Joel Shapiro, San Francisco
There's a lot I really like about FileMaker 14's new Button Bars (especially that segments can be used as layout-level calculations! :), but one problem I'd had was that I didn't know how to "de-activate" a button bar segment (i.e. return it to its Inactive state) — so it remained showing the style set in the Inspector for Active state. Of course this is a good feature for things like navigation bars, where you WANT to keep the Active state as you navigate through records, etc., but there've been times I've used an old fashioned button (not button bar) because I didn't know how to deactivate its state after it had been clicked or tapped.
Now I've found a way:
Set the Button Bar's Active Segment to Specify… "" (or really anything other than the name of any of its segments) instead of 'None', and give the Button Bar an Object Name. Then, to deactivate the button, just refresh the object.
At this year’s CWP User Group at FileMaker DevCon, there were five of us who shared with the group:
I started things off (details below)
Todd Geist demoed his new sails-filemaker
Salvatore Colangelo from Goya showed their newly open-source RESTfm
Masayuki Nii demoed INTER-Mediator (See his slides)
Mark DeNyse showed two-factor authentication & file-caching in CWP (Get his demo files)
The year of connecting differently
As I started the meeting, I commented on how this past year has seen some new ways of connecting to FileMaker Server. Not only can people do Custom Web Publishing in the “traditional” ways of:
FM API for PHP
FX.php
XML Web Publishing
ODBC
we now have:
FMAngular: “FileMaker tools for AngularJS” by Sam Barnum/360works
fmxj.js: “a JavaScript approach to FileMaker Custom Web Publishing” by Jason Young/Seedcode
sails-filemaker: a “filemaker adapter for Sails / Waterline [node.js]” by Todd Geist
RESTfm: “PHP code that turns your FileMaker Server into a RESTful Web Service” (neither new nor JavaScript-based, but newly open source:) by Goya
It’ll be interesting to see how developers take to these exciting new approaches and how they may change the ways we connect to FileMaker data. It’s certainly a changing Web we live in.
My time on the soap box…
I began by sharing a few quick tips:
PHP Linting Let your editor find your PHP errors! I use linter-php for Atom. Save yourself from the dreaded blank page & find the appropriate package for whatever editor you use (or change editors! :)
Chrome “People” (for logging into your sites w/ multiple access levels at the same time, for "clean/vanilla" browser experiences, etc.)
tota11y accessibility tool by Khan Academy
Responsive CWP
I then lamented that — as much as I love Responsive Web Design — few CWP sites that I've worked on are good candidates for responsive design. Most are more like "apps" and really need a large screen so users can see all pertinent data that they need to interact with. If their target audiences really had to be smartphone users, then these sites would need a total UI redesign, not just a switch to responsive design.
Fortunately, simpler CWP sites can in fact work really well in a responsive design, and they don't necessarily need a lot of changes to make that happen. I walked through the steps I took to retrofit a small single-form CWP site into a responsive site targeted specifically for a company's iPad-using employees.
…and these are the tools & tips I showed in my demo:
Responsive Resizer Bookmarklet (based on the awesome Viewport Resizer but w/ iPhone 6 & 6+)
Chrome DevTools and their Device Mode
Real Favicon Generator for touch icons on mobile devices
Use <a href="tel:+12345…" to turn phone numbers into callable links
A big THANKS to everyone who came, and to Salvatore, Mark, Todd and Masayuki for sharing.
FileMaker checkbox fields can be pasted into - and you might never see it
I recently made a discovery that really surprised me:
FileMaker fields set to display as checkboxes can be pasted into!
I'd never really thought about it, but I guess I've always just assumed that these layout controls limited the values that could be entered. Clearly, that is not at all the case. If a field has focus, any manner of pasting (Edit>Paste, Command/Control+V, contextual menu) will paste into that field. In the situation where I discovered this, I'm guessing that the user was unintentionally in the field when she pressed Command/Control+V. Then she just checked or re-checked her desired values and never even knew that there was bad data in the field since it didn't show in the interface.
Certainly it's possible to set the field validation to Require "Member of value list: x", but there are times you may not want to do that.
Fortunately, a simple OnObjectExit script trigger can come to our rescue.
The script consists only of one Set Field step, with Specify target field left blank (since it runs on the active field).
It is completely modular, only requiring the relevant Value List name as the script parameter.
Let ( _values = FilterValues ( //textToFilter: Evaluate ( Get ( ActiveFieldTableName ) & "::" & Get ( ActiveFieldName ) ) ; //filterValues: ValueListItems ( Get ( FileName ) ; Get ( ScriptParameter ) ) ) ; // strip trailing carriage return MiddleWords ( _values ; 1 ; Length ( _values ) ) // from fmfunctions.com/fid/355 )
Note: Using FilterValues and ValueListItems functions adds a trailing carriage return, which is why I added the MiddleWords function.
Easy, attractive dividers for HTML select elements (drop-downs)
HTML <select> elements, however, have no easy (nor inherent) way to add dividers.
And if you're building web sites for people that are used to building FileMaker Pro interfaces, it's likely you have been — or will be — asked to include dividers in drop-downs on their website.
When I got the request, I first thought of using <optgroup>s and/or hyphens, but then I found a really nice — and simple — way to add clean dividers to <select> elements on stackoverflow: a horizontal unicode box drawing character and a disabled attribute.
To make it even easier, you can just copy/paste the unicode character — you don't need to use the actual unicode (e.g. U+2500).
Chrome 37 adds Autofill on detected addresses etc on OS X. Use Autocomplete Off to suppress it
Google Chrome 37 just came out, and I was surprised to discover that it brought some changes to how it deals with some web forms.
Basic testing showed that the following cause this behavior:
a set of 3 inputs with labels "Address", "City" & "Zip" (regardless of input name) - All 3 offer Autofill
(but not if there are only 2 of them)
a set of 3 inputs with names "address", "city" & "zip" - Only "city" & "state" offer Autofill
(although not if they are the only 2 inputs in the 'set'; it seems there must be a minimum of 3 inputs)
Note: changing "address" to "street" does offer Autofill on that input as well.
a single input with name "city" IF elsewhere on the page there is a set recognized as an address
inputs recognized as email addresses & phone numbers can also be impacted
Of course there may be times when you're happy to provide users with this option (e.g. if they're entering their own address), but if they'll be entering an address that's not likely to be in their Contacts, you'll probably want to turn this off.
By adding HTML5's autocomplete="off" to the <form>, we can suppress Chrome's new behavior.
You can see the new behavior on BrowserStack, where Chrome 36 and below do not behave like this while Chrome 37 (currently "37.0 beta") and above do. If you're on Chrome 37 Mac &/or have a BrowserStack account, you can check out my CodePen pen.
FWIW: Clicking the "Enable Autofill using Contacts…" prompts you to allow Chrome to access your Contacts. Stating "No" sets something (in Chrome &/or in System Preferences > Security & Privacy) that I couldn't figure out how to turn back on :(
A collection of FMP URL, Web Viewer and Data URL examples
If you have or know of any others, please add them in the comments.
During the unconference session:
I dove into my:
• Responsive Web-Viewer Layouts: FMP URL & JavaScript
• DevCon2Go13_WebUI: A web-like UI for DevCon2Go 2013
Mark showed us his:
Scheduling/project-management solution using FullCalendar (jQuery) & FMP URLs within a Web Viewer
Other cool examples:
A collection of videos, including Web Viewers as on-hover script triggers (without plug-ins), by Osamu Noda (@sam_oda)
WebViewers, Javascript and FileMaker: Enhanced integration possibilities via WebWorkers by Steve Senft-Herrera (Steve also has 2 other examples in the comments below)
Clickable map using SVGs & FMP URL in a Web Viewer by Mallverkstan (@mallverkstan)
The FileMaker Web Viewer as a Javascript Calculation Engine (CSV to JSON example) by Jason Young (@TeraPicoData)
Web Viewer DataURL examples from Dan Shockley (@DanShockley)'s DevCon 2013 session (FM12, see layouts: "Web Viewer 1-6")
Commercial calendar examples:
Calendario en HTML5 para FileMaker Pro 13 by José E López Rosario (@SolutionsCay)
(free/unlocked for personal use)
FMCalendar by La Source multimédia (@lasourcefr)
Resources:
FMP URL protocol infographic (PDF) by Tony White (@tonywhitelive)
FMP URL Scheme and the 13.0v2 Improvement by iSolutions (@isolutionsinc)
Getting Started with Javascript and FileMaker by Soliant (@soliantconsult)
Native Web 2.0 Controls in FileMaker 12 Layouts by Brian Schick (@brian_schick)
Use single quotes for HTML attributes in FileMaker Data URL Web Viewers by me
Ongoing collection of my relevant blog posts & demos by me (@jsfmp)
Andrew Duncan presented Surviving a Security Audit – how to best prepare for a security assessment of your FileMaker PHP web application
Mark DeNyse showed Custom Web Publishing with FullCalendar - Integrate the jQuery plugin FullCalendar into your CWP solution. Demonstrates how to pull data from FileMaker and display on the calendar, handle drag and drop, event resizing, etc.
Tim Dietrich shared more of his FMWebFrame, which extends the official FileMaker API for PHP, making it easier to develop advanced Web solutions that integrate with FileMaker databases.
During my time on the soapbox, I presented a few quick tips that I'm using all the time now, and then I started a conversation...
I wanted to explore issues around the huge amount of web development & design techniques/tools/etc. that CWP developers could learn, staying mindful of the relatively small pool of CWP developers in the world (compared to the pools of FileMaker developers, web developers, etc.) and wanting to leave CWP projects that other developers could pick up after me.
I ended by proposing an idea for us as a community to contribute to a list of "learnable things" for CWP developers, ranked on how valuable they may be to CWP development in general as well as to someone's or their team's development processes.
Here are my slides.
If you've got ideas on good ways to implement the "learnable things" table online, please let me know!
FileMaker 13 Animated Slide Panels with Web Viewers
SeedCode just posted a cool example in which they "simulate a drawer effect in FileMaker where an animated slide panel appears to withdraw completely into the window edge". Unfortunately, they mention "the big downside here is that panels aren’t 'blockers' so buttons etc behind the tab panel still work".
This made me think of Web Viewers since they always float on top of all other elements on a layout, and they do block all interactions with any elements that lie beneath. Thinking this could be another use-case for our friend FMP URL, I whipped up a quick demo.
UPDATE:
This is my fastest blog-post-into-irrelevancy turnaround yet. Per Daniel Wood's comment (see below), none of this Web Viewer stuff is necessary :-P Still, maybe you'll find some of the techniques here of interest, even if not appropriate in this situation. Or just carry on with the rest of your Interwebz. Thanks, Daniel ;)
Download the demo file (.zip) The Slide Panel buttons are on the top right.
What I did:
Placed a Web Viewer onto a new Panel of the Slide Control (so as to keep the original) and made it the same size and position as the original element
Set the Web Viewer to use a Data URL and set the CSS for the background to be the same gradient used in the original
Selected each button, opened it in the Preview app (via File>New) & saved it as a JPEG
Normally I'd just use CSS for buttons, not images, but I wanted to make this (quickly) like the original
Created Base64 strings of each button image via an online Base64 image converter
Changed double-quotes in the Base64 image tag to single-quotes so there's no need to escape them
Wrapped each Base64 button inside an <a> element (for a clickable link), set the href attribute to an FMP URL, and placed them on the Web Viewer
Created a GoToLayoutByParameter script to be called by the FMP URL
Set the CSS for the images so they would center and be positioned like in the original
The FMP URL:
"<a href='fmp://$/" & Get ( FileName ) & "?script=GoToLayout¶m=LayoutName'>"
What I noticed:
This worked well, and the Web Viewer did indeed block the behaviors of the underlying elements (on-hover visual changes and clickable buttons), however I discovered that the contents of the Web Viewer didn't render until the full panel was displayed, which meant that the background gradient and the buttons weren't visible during the sliding animation :(
What I changed:
Created an additional Panel of the Slide Control
Set the Web Viewer itself to have the same gradient as the original element (as opposed to the default solid color of white)
Placed copies of the button elements on top of the Web Viewer so they display during the slide animation (Once the Web Viewer is rendered, these buttons are hidden underneath) The images aren't perfectly lined up, but it's good enough for the demo.
What I think:
Well it ain't perfect. The copies of the buttons on top of the Web Viewer in particular feels inelegant & kludgy.
Is it an improvement on the non-WebViewer versions? Dunno.
"A web-app interface for your FileMaker database" — Revisited, Released, Unlocked
Please see Responsive FileMaker Design & Web-Viewer Layouts ( the trailer ) for more details, the inspiration, and a screencast video showing how to use the file, etc.
Caveat
There are still some issues that I wish were better dealt with when using these techniques, which is the main reason I never updated my demo file until now. My main frustration is that the protocol can only be used on a given computer in either FileMaker 12 *OR* 13, not both. So if your computer is set to use the FMP URL protocol with FileMaker 13 and you try to use an FMP URL in a database open in FileMaker 12 (or vice versa), it won't work. It may try to open 13, but won't have the context from which it was initially run. For Mac users, there is a downloadable preference pane that can be used to select the default application for the FMP URL, although this doesn't remove the problem of 12 *or* 13. This problem also exists on Windows. I haven't tested this, but maybe it can do something similar. Either way, it's a real drag that we can't just trust that a solution we build using Web Viewers and the FMP URL will work for all users -- without the possibility that they may need to download & configure something just in order for it to work.</rant>
Demo = (a) Web Viewer interaction + (b) "Responsive"
As a brief review, there are two main components to this demo file:
It uses a Web Viewer, the FMP URL protocol and JavaScript to read from and push to the underlying FileMaker fields.
The layouts are "responsive"—using techniques from "Responsive Web Design"—which means a single layout adapts to screen sizes from iPhone (FMGo) to desktop.
These two components don't need to go together, but it was really the "responsive" part that pushed me to experiment with all this in the first place. However, since the FMP URL is the thing that's changed with 13.0v2, that's what I'm focusing on in this post.
Overview (fmp:// URL, called by JavaScript, on Responsive "Web-Viewer Layouts")
The data-entry layouts contain only a Web Viewer. The web viewer uses a Data URL that inserts the relevant field contents into <input> elements within an HTML <form> element (like a form you'd fill out on a website). As you navigate through the records, the Web Viewer is updated with the data of each record.
When you submit a change to the data — either via the Submit button or by hitting Return/Enter on a regular keyboard or touching "Go" on the iOS keyboard — JavaScript sends the contents of all fields, along with their respective field names, as a single parameter to an FMP URL that then calls a "PerformEdit" FileMaker script on that record. This FileMaker script in turn parses the parameter into name-value pairs (field name & field value) and then uses the Set Field By Name script step to update the record.
The JavaScript
NOTE: You do not need to understand or modify this JavaScript in order to incorporate these techniques into your database.
$('form').submit(function(){ var str = $('form').serialize(); var encStr = encodeURIComponent(str); var replStr = encStr.replace(/%3D/g,':::').replace(/%26/g,'|||'); $(this).attr('action', '" & FilePath_cf & "?script=PerformEdit¶m=' + replStr ); });
Basically, when the form is submitted this grabs all of the field names and field contents and places them into one text string. It then encodes that string to be "URL-safe" and then replaces the specific "=" and "&" characters that define the key-value pairs in that encoded string with other text strings to make things easier on the FileMaker side
Here are the three versions of the string before it gets sent to FileMaker as the fmp:// parameter:
1) As captured via the jQuery serialize() method [ var str ] :
You can see in this last iteration, the ampersand character that divides the key-value pairs (as seen in the initial version of the string) has been replaced with "|||", yet the ampersand entered in the Company field, "Doe & Doe", retains its standard URLencoded string "%2526".
The FileMaker Script
The FileMaker script first decodes the JavaScript-encoded string (step 2, above) via a custom function. It then replaces all occurrences of "|||" (step 3) with pilcrows (¶) so that the one long text string becomes a list of key-value pairs, with the field name and the field value separated by the ":::" string. The script then just loops through all these pairs, and uses the Set Field By Name script step to update all fields:
Set Variable [ $vals; Value:Substitute ( URLDecode_cf ( Get ( ScriptParameter ) ) ; "|||" ; "¶" ) ] Set Variable [ $fieldCount; Value:ValueCount($vals) ] Set Variable [ $i; Value:1 ] Set Variable [ $error; Value:0 ] Set Error Capture [ On ] Loop Exit Loop If [ $i > $fieldCount ] Set Variable [ $parseKeyValuePair; Value: Let ( [ _row = GetValue ( $vals ; $i ) ; _pos = Position ( _row ; ":::" ; 1 ; 1 ) ; $fieldName = Get( LayoutTableName ) & "::" & Left ( _row ; _pos - 1 ) ; $fieldValue = Substitute ( Middle ( _row ; _pos + 3 ; 9999 ) ; "+" ; " " ) ] ; "" ) ] Set Field By Name [ $fieldName; $fieldValue ] If [ Get ( LastError ) <> 0 ] Set Variable [ $error; Value:Get ( LastError ) ] Exit Loop If [ 1 ] End If Set Variable [ $i; Value:$i + 1 ] End Loop If [ not $error ] Commit Records/Requests End If Exit Script [ Result: $error ]
Using the demo; Incorporating with your own data
The demo contains two separate layouts that both interact with the FileMaker data as described above:
A generic template layout, named "SomeLayout", which any FileMaker user should be able to modify and use with their own data. As demonstrated in the video on the original post, you only need to place the relevant fields onto a standard FileMaker layout (with the appropriate naming convention; in this demo it's "SomeLayout_fields") and the Web-Viewer layout will place all those fields automatically into the web form.
A "customized" layout which uses significantly more complex CSS, JavaScript and some HTML5 — to give an example of what could be possible for developers with more web development skills.
Both layouts are Responsive. And with rumors of a larger screen coming with the iPhone 6, this could be another good reason to use these techniques over separate layouts for each device/window size…
Download the Demo File
This is the same file from my original post; cleaned up a bit, unlocked, and still happily not perfect :)
In fact, navigating records natively in FMGo13 now looks very odd in the "Customized" layout because of the slide effect — so I'd probably remove the Status Bar on a production file like this for FMGo. Also, Internet Explorer 9 does not support columns in CSS so on Windows with IE9, the template layout is always just one column. There are other options if you need to support IE9.
Get it zipped (.zip) or unzipped (.fmp12) (for FMGo)
And remember to check out my original post to see more of how to use this file.
Other possibilities…
There are a number of additional advantages to using "Web-Viewer layouts". Because the whole interface is essentially a web page, you could incorporate almost any web technologies into a Filemaker interface. Pretty much anything you've seen on the Web (specifically in Safari &/or Internet Explorer, since those are what run FM Web Viewers) could be brought into FileMaker. Think of user-friendly web forms with instant field-validation, hints, "masks" that only allow the input of certain characters (e.g. "(___) ___-____" for U.S.-type phone numbers, in which typing a letter character won't even display), etc.
Also, because the styling of the layout is done via CSS in a text field, you could potentially open up modification of layouts to anyone with edit-access, including in FileMaker Go!
FileMaker 13 has brought in some great new web-like UI features such as hiding elements, popovers and slide controls, but there's still plenty in the world of web design that can only be implemented in FileMaker via Web Viewers. And now since 13.0v2, there's very little reason (see Caveat, above) not to start implementing them now.
*Other FMP URL examples:
http://www.filemakerbloggen.se/post/a-clickable-map
http://www.isolutions-inc.com/?p=1727
http://www.soliantconsulting.com/blog/2014/04/getting-started-javascript-and-filemaker
http://www.seedcode.com/filemaker-webviewer-javascript-calculation-engine
& my "A web-like UI for DevCon2Go (2013)" from last year's DevCon
Please add additional examples or resources in the comments.
And let me know what other kinds of things you might build with these techniques!
Capitalizing accented letters: strtoupper vs mb_strtoupper (or via CSS)
If you've got accented letters in FileMaker, they come out to the web retaining their accents, but what if you want to capitalize those letters on your web page? For me at least, it wasn't as simple as I'd expected.
PHP's strtoupper() capitalizes non-accented letters but leaves accented letters lowercase
PHP's mb_strtoupper() will capitalize accented letters when you include an encoding parameter
CSS's text-transform: uppercase capitalizes all text, including accented letters
$string = 'Léa'; echo strtoupper($string); // outputs LéA echo mb_strtoupper($string); // outputs LéA echo mb_strtoupper($string, 'UTF-8'); // outputs LÉA echo '<span style="text-transform: uppercase;">'. $string. '</span>'; // outputs LÉA // (note: I'm using an inline style for brevity. I recommend using classes with CSS)
So unless you're sure there won't be accents in your capitalized text, use mb_strtoupper or text-transform.
n.b.: The "mb_" stands for multibyte:
"While there are many languages in which every necessary character can be represented by a one-to-one mapping to an 8-bit value, there are also several languages which require so many characters for written communication that they cannot be contained within the range a mere byte can code (A byte is made up of eight bits. Each bit can contain only two distinct values, one or zero. Because of this, a byte can only represent 256 unique values (two to the power of eight)). Multibyte character encoding schemes were developed to express more than 256 characters in the regular bytewise coding system."
http://www.php.net/manual/en/intro.mbstring.php
