Debugging in ExpressionEngine
Tags: debugging, expressionengine, eecms
Published: 2019-02-22 13:45:55

---
title: Debugging in ExpressionEngine
published: true
description: 
tags: debugging, expressionengine, eecms
cover_image: https://thepracticaldev.s3.amazonaws.com/i/c05qxnpz5oadmbqnbct9.gif
---

In 2017 I gave a [presentation at EECONF](https://speakerdeck.com/boldminded/stop-using-var-dump-embrace-step-debugging) in Denver about step debugging in PHP, specifically in the [ExpressionEngine](https://expressionengine.com) CMS, however, I didn't go into debugging issues in template code. ExpressionEngine is a bit of a different beast than other PHP based content management systems. It has a very easy to learn template language, but it is also a bit nuanced. Templates are string based, and have multiple parsing steps. [Low](https://expressionengine.stackexchange.com/users/172/low) did a great job explaining the parse process in this [StackExchange](https://expressionengine.stackexchange.com/questions/6/what-is-parse-order-and-how-does-it-affect-how-my-template-is-coded-rendered) thread. Since templates are parsed, you step debug the PHP that is parsing them, not the template code directly.

Debugging template code is something I do often when developing an ExpressionEngine site myself, or helping a customer debug [one of my add-ons](https://boldminded.com). Instead of getting a specific error message, a template tag may simply not be outputting the content they are expecting. Occasionally I ask them to share the template code they're using and I get a _full_ template file with a few hundred lines of code. This to me indicates they don't know where to start debugging the issue themselves. For example, my [Publisher](https://boldminded.com/add-ons/publisher) add-on is very complex, and one of it's main functions is to display translated content in the `{exp:channel:entries}` tag. To do this it uses the `channel_entry_query_results` hook in ExpressionEngine. It's very common to have multiple `{exp:channel:entries}` tags on a page, and each one of them calls the `channel_entry_query_results` hook. That means the code I need to debug is getting called multiple times. This is especially an issue when I have to FTP to someone's site and debug it myself. I can't remotely step debug (well I can, but that requires server config changes and I can't ask a customer to do that), so I usually resort to `var_dump();` or writing to a local log file. If the issue resides in a single `{exp:channel:entries}` tag, but there are 2 other `{exp:channel:entries}` tags on the page, then the code I'm debugging gets called 2 additional times, both of which may be unrelated to the issue I'm debugging. Imagine playing *Let's Make a Deal* and you're presented with 3 doors, and you have to pick the correct door to win the prize, in this case the prize is the bug. Trust me, this isn't a game a developer wants to play. Spending time choosing and venturing into the wrong doors is wasted time and is often frustrating. Those additional hook calls are just getting in the way and adding noise. As a developer I want to avoid the noise and isolate the issue as quickly as possible.

The solution: **Simplify**

Remove the two other doors from the equation. Remove **everything** from the template that is not directly related to the issue you're trying to solve. This mean removing the header, footer, navigation, and possibly even all JavaScript and CSS code. Break it down to the bare necessities to replicate the bug.

What do you do if you don't know which template code is the problem child? Start removing chunks of code until you can isolate which area, or template tag specifically is identified as the one causing the problem.

Here is a use case from a support ticket I recently had. The customer had 3 channels: Pages, Publications, and Documents. The Page entry was using a [Bloqs](https://eebloqs.com) field to display an entry from the Publications channel, which itself had a relationship field to another entry in the Documents channel. Then the documents channel had a custom file field which contained a PDF. They were also using Publisher to display all of this as translated content in two different languages. The bug in this case was that the file field in the Document entry would always display the default language value `english.pdf`. I first tried to debug the issue with the template code they provided:

```
{exp:channel:entries entry_id="3"}
    <h1>{title}</h1>
    {bloqs_field}
        {related_publication_bloq}
            <h2>{title}</h2>
            {related_document}
                <h3>{related_document:title}</h3>
                file: {related_document:file}
            {/related_document}
        {/related_publication_bloq}
    {/bloqs_field}
{/exp:channel:entries}
```
Note that the provided code is already very simple. The customer took the time, at my request, to setup a brand new ExpressionEngine environment with only the bare necessities to re-create the issue. He removed the noise. This was extremely helpful to me and is something I ask of customers quite often.

After a bit of step debugging (they sent me a full copy of the test site to run locally) I was still not sure what the cause of the problem was. I had spent nearly an hour trying to figure it out. To simplify the issue I broke the template tag above into 3 separate `{exp:channel:entries}` tags. After all each `{related_` field is just calling another entry. So I broke the template out into the following, which is essentially doing exactly the same thing as the previous code snippet, but in 3 separate `{exp:channel:entries}` tag.

```
<!-- Page -->
{exp:channel:entries entry_id="3"}
    <h1>{title}</h1>
{/exp:channel:entries}

<!-- Publication -->
{exp:channel:entries entry_id="2"}
    <h2>{title}</h2>
    {related_document}
        <h3>{related_document:title}</h3>
        file: {related_document:file}
    {/related_document}
{/exp:channel:entries}

<!-- Document -->
{exp:channel:entries entry_id="1"}
    <h2>{title}</h2>
    file: {file}
{/exp:channel:entries}

```

With all three of the entries on the page at once I could see which was working and which was not, and it was immediately apparent that the `{file}` field was not printing the correct value. I then commented out the first two `{exp:channel:entries}` tags and step debugged the 3rd one. Since it was the only `{exp:channel:entries}` tag on the page with no `{related_` fields I didn't have to deal with extra debugging noise and got to the source of the problem in a couple minutes. Even if you're not step debugging simplifying templates lets you hone in on problem areas, thus getting you to the solution faster.