As FileMaker developers, we rely heavily on FileMaker Pro Advanced, which lets us step through scripts and test variables on the fly. Unlike in FileMaker, there is no Data Viewer and Script Debugger to make life easy in PHP development. We can take a manual approach or just as with FileMaker solutions write a custom function to do all the heavy lifting.
The Old Way
When trying to decide the content of variables that fail, developers usually print these to the web browser, using either “echo” for strings or “print_r” for arrays.
We quickly discover that large arrays look messy with just print_r, and so the next step is to wrap some “pre” lines around this to format the array into more readable text.
echo '<pre>'; print_r( $array_name ); echo '</pre>';
Even these three lines can get end up crowding your page as you are writing code. When stepping through the various arrays returned by the PHP API for FileMaker using a newFindCommand, adding these three lines in between each variable, and then commenting these out while debugging, can become tedious. The simple query below has five possible places you might want to check the content of the variable.
$find = $fm->newFindCommand($layout); $find->addFindCriterion('field', $value); $result = $find->execute(); if(FileMaker::isError($result)) { $error = $result->getMessage(); die($error); } $records = $result->getRecords(); $record = $records[0];
A Better Way
Writing a function for PHP is somewhat similar to the method in FileMaker. The function requires a name, parameters, and calculations to serve the purpose of the function. You can store your functions in a separate functions.php page that you include in your PHP page, and call the function as needed. The function that I created to check what happens to each variable takes an optional parameter in the end to decide whether to output to the browser. So, I can include this function as one line in multiple places without worrying about commenting out the code.
function display_debug($key, $value, $debug=false) { if($debug){ echo ''.$key . " = "; switch (gettype($value)) { case 'string' : echo $value; break; case 'array' : case 'object' : default : echo ''; print_r($value); echo ''; break; } } }
There’s nothing too fancy here. I have in fact borrowed the main part of a function that comes with the PHP Site Assistant installed by FileMaker Server. It checks whether the variable is a string or array. I modified the function to include the key or variable name in bold, and also added the “pre” around the print_r to format the array.
Using the Debug Function
When I need to call this function, I simply call one line. The default has only two parameters.
display_debug('$findall',$findall);
Without the optional third parameter, nothing appears on the page. Add a “1” and this function becomes live.
display_debug('$findall',$findall, 1);
The variable inside quotes will let this appear as text, letting you search if multiple variables appear on the page. Often you need stop points after certain sections of code, in which adding the command “die();” would let you focus on just that section.
Debugging code is part and parcel of any development effort. Even when everything seems to work great, to echo the arrays or strings stored in variables validates your code and acts as a sanity check. Testing for errors or determining the cause of errors require stepping through all possible locations this may happen. With a function handling displaying the variable contents and not using print_r() on each page, your code ends up cleaner on each page and cleaner overall.
I have built sites with functions similar to this. I have a standard includes page that sets up certain site level variables, and I usually include a line:
$_siteDebug = true; //or false to hide debug info
on my pages I also include a line
$_pageDebug = true; // or false to hide debug info
then in my debug functions parameter, include something like
display_debug(‘$findall’,$findall, ($_pageDebug || $_siteDebug));
Thanks, Mark. This is a neat enhancement.
Great wrap-up!
My first thought was this is similar to what I have been doing since I learned PHP a few years ago. But then I discovered something very bad about myself…
I almost ended up writing a full-page comment here, then I rather posted it as a separate article: PHP Debugging & FileMaker Custom Functions Do Exist
Hi HOnza, nice article. I do wish the FileMaker custom function repositories were somewhat more organized, but the first place I turn to when I need a custom function is Brian Dunning’s web site. Usually I find what I need there, but often it takes some time testing various similar functions. Not sure if there are enough FileMaker PHP developers to justify a PHP function repository aimed for FileMaker, but that might be the next logical step.
I’ve not spent much time within FileMaker’s PHP api lately, and I admit I didn’t read through the whole article… but are you guys not aware of using Xdebug and an IDE for doing PHP code?
http://xdebug.org/
http://komodoide.com/
Anyone doing serious coding within PHP should be using xdebug plus other helpful tools such as
https://addons.mozilla.org/en-US/firefox/addon/easy-xdebug/ (if using netbeans as your IDE)
Hope that helps some of you out.
Hey Matt, thanks for the links. I intended this as an introductory article, but I’ll probably do a follow-up or two about more advanced environments. A discussion of IDE software certainly bears merit. Netbeans has some advantages, but I have also tried Eclipse and Aptana Studio, as well as Zend Studio. And that doesn’t begin to cover the better text editors, like Coda, TextMate, BBEdit, Komodo Edit, and a whole host of other ones available. And there’s the are CMS solutions like WordPress, Joomla, Drupal, Cake, CodeIgniter (which I’ve been able to integrate with FileMaker using FX.php thanks to some other path-breaking developer).
I use free Codelobster to debug PHP code with any frameworks.
CodeLobster certainly looks interesting, though it’s a Windows OS only application. Thanks for mentioning this tool.