Debugging Smarty templates

Joor Loohuis, April 22, 2009, 6129 views.

Debugging Smarty templates becomes more difficult as the complexity of the assigned data increases, and may also depend on the sophistication of the application. Another twist is added when changes need to be made to a live application. This article gives a couple of tips for making debugging templates a little less painful.

Tags: PHP, smarty, web, webdevelopment

Smarty is a very flexible, powerful, and popular PHP template engine, used in developing websites, but more importantly, web applications. The complexity of a template and the amount of data assigned to it can rapidly grow, and determining the origin of a problem becomes more and more difficult. Add to this that there are many occasions where changes must be made to a template in a production environment. In all these situations, a sensible approach to debugging is required.

For your eyes only

First of all, there is no reason why anyone other than you and other developers shoud see the debugging output. Not only is it pointless, but it might compromise the security of your application by exposing information that is not supposed to be transmitted to the client. So encapsulate all your debugging statements in a construct that prevents this. For example:

{if $smarty.server.REMOTE_ADDR == '111.222.333.444'}
{debug}
{* other debugging code goes here *}
{/if}

Here we look at the IP address, and only emit debugging output if it matches one specific address. That might not work for you, for example if your users are behind the same IP address. You may use any test to shield the debugging output, or combine several tests:

{if $smarty.server.REMOTE_ADDR == '111.222.333.444' &&
    $smarty.request.smartydebug == 42}
{debug}
{* other debugging code goes here *}
{/if}

In this example you would not only have to be working from a specific IP address, but also have to add a query string to your request:

http://www.example.com/myapp.php?smartydebug=42

Builtin debugging tools

Of course Smarty provides a debugging console which contains all information assigned to a template. You access it by adding {debug} in your template as is done in the examples above. The placement of this instruction is important, since Smarty will modify the assigned variables not only when you use {assign}, but also in {foreach} loops and other constructs. Of course, using instructions like {config_load} will also affect what the debugging console displays.

Request and configuration info

When debugging an application, it is often useful to take a peek at what information was sent to the server. For example, for AJAX requests that return HTML generated with a template, it is difficult to find out what information the server received (unless you're using Firebug, of course). If you add the following code to your template:

{if $smarty.server.REMOTE_ADDR == '111.222.333.444'}
<pre>
{$smarty.request|@print_r}
</pre>
{/if}

you get a nice list of all request parameters that resulted in this HTML to be output. You could add a similar construct for $smarty.session, and probably less useful, $smarty.cookies. If your application or site uses URL rewriting of other techniques, $smarty.server may also contain very valuable information. More static between requests, but occasionally handy is $smarty.env.

Remove your debugging code

Finally, when everything is working smoothly, don't forget to remove your debugging constructs. At the very least, place Smarty comments around your debugging code, but it is better to remove them altogether. If you have a grabbag of little bits of Smarty template code, you can always copy and paste debugging code from there, so there's no real extra effort involved in resuming your debugging at a later stage.