• Development

    Using Xdebug to Trace Functions

    I’ve been relying on Xdebug quite a lot in recent years to step through PHP code, analyze stacktraces, inspect variables, profile applications, and more. Recently I needed to find out why a function call was taking so long to execute. Using Xdebug’s trace functionality made this task pretty simple. Here’s how Xdebug describes function tracing:

    Xdebug allows you to log all function calls, including parameters and return values to a file in different formats.


    Those so-called “function traces” can be a help for when you are new to an application or when you are trying to figure out what exactly is going on when your application is running. The function traces can optionally also show the values of variables passed to the functions and methods, and also return values. In the default traces those two elements are not available.

    Having Xdebug trace your function calls is simple enough, and well-documented across the web. You can see my recommended settings at the bottom of this page, and here’s a good resource on the subject: http://devzone.zend.com/1135/tracing-php-applications-with-xdebug/

  • Development

    Introduction to FirePHP

    FirePHP is a great tool for debugging PHP, and maintaining some level of control over your error handling. Also, it’s a great tool for getting information about your variables, objects, etc. while your PHP code is executing. FirePHP requires only a small amount of setup and can be reused time and time again without tedious setups for each site on your server. This tutorial/example requires Firefox and Firebug, and FirePHP.

  • Development

    Cache-related WSOD! Help!

    UPDATE: You can do this stuff with Drush (setting the variable with vset). It’s much faster!

    Well, you’ve probably all had a White Screen Of Death a time or two while dealing with Drupal or PHP. They can be very frustrating, but are usually easy enough to resolve. The following illustrates how to recover from a Drupal WSOD as a result of making changes to your cache settings in the Site Configuration -> Performance admin page. Again, this “fix” should only be applied if you have issues that you know are related to recently altering the cache/aggregation/compression settings.

    The fix requires a little bit of database work. Basically, you need to modify a few rows of the variable table. This table is where many of your Drupal settings are stored. Here’s a screenshot of the variables you need to set. The values you’re seeing are in the form of serialized data. To fix the WSOD, we need to disable all of the caching. This is accomplished by setting the values in between the quotes from 1 to 0 for all of these rows (except ‘clear’). If the rows don’t exist, don’t worry about it; this means the feature hasn’t been enabled. If you are uncomfortable modifying the values, you can actually delete the rows. Just make sure, when you re-gain access to your site, you visit the Performance settings page and re-save it. You don’t even have to enable anything. The act of saving this form should re-write all of the rows to the variable table.

    cache_wsod