The Perfect Support Request

June 16, 2009

I’m a busy guy. I have a demanding job at a web agency, and when I’m not at work, I craft add-ons for ExpressionEngine. And then I support them.

Support is often like doing taxes: time-consuming, confusing, depressing, and unfortunately, unavoidable.

But earlier this evening, I witnessed something I never dreamed possible: the perfect support request. So, in hopes that others might learn a thing or two from it, I’ve decided to critique it here.

The ticket, “Playa tags not rendering”, was submitted by the adorable Mahalie. Her title alone is worth mentioning for its clarity and conciseness.

Let’s dive in.

She begins with a bit of humor to lighten the mood, drawing attention away from the daunting title and blood pressure-raising red background:

I'm starting to feel like I have some kind of serious mental challenge!!

Then, quickly gets down to business with details on her server environment:

EE 1.6.7, PHP 5, FieldFrame 1.1.3

Now, watch how she retraces her steps, pinpointing exactly where things stopped behaving as expected:

Installed Playa 2.0.7 after I got FF totally working. The install seemed to work, no errors, CP/setup was smooth and admin/publish page looks right too. Editing an entry using Playa and selections are still there so it seems to be writing to db. My playa field is called 'lp_selected'.

{if lp_selected}
  <p>I can see it!</p>
  {lp_selected}
    {title}
    <p>Yes! I'm inside...</p>
  {/lp_selected}
{/if}

I can see it shows up. That is the tags seem to be parsing but don't return anything. I never get any titles or even my test message that I'm in the loop. I have tried just using {lp_selected} to see if anything would output, to no avail.

Did you catch that last sentence? Let me repeat it again, just in case:

I have tried just using {lp_selected} to see if anything would output, to no avail.

That’s what we like to call “troubleshooting”. Sure, it didn’t actually solve the issue, but it provided valuable information that crossed-out one possible explanation. It’s the first thing I would have asked her to do, had she not done it already.

She also confirmed that there wasn’t a typo by adding an intentionally meaningless tag, and that it wasn’t an extension conflict by disabling all other extensions.

But she didn’t stop there:

I have checked my path in settings, as mentioned I have several other fields including an FF Matrix working on the same template. The path is not relative as was mentioned in the other similar issue to this.

I can’t tell you how many times people ask me something that I’ve already answered time after time on Get Satisfaction. Very frustrating at first, but I’ve come to expect it. To see that Mahalie has actually taken the time to see if anyone else has had a similar issue, and logically deduced that hers is unique, is nothing short of fascinating.

She concludes with an annotated screenshot of her Playa field (a great way to ensure that we’re both on the same page!), and thanks me in advance for taking the time to help her.

Folks, this is how it’s done. She did her own troubleshooting. She made sure her problem was unique. And when all else failed, she came to me in good spirits.

But only Jesus is perfect!

OK, fine. There was one small quibble: the issue ended up being something that is documented on Playa’s Overview page:

status="open|my_custom_status"

Filter the selections by status. Prepend the value with “not ” to specify which statuses to exclude. Leave the value blank to include all statuses. (Default is “open”.)

(Her entries were assigned a custom status, so she needed to override the status param’s default "open" value with "not closed" or the like.)

Of course, fault here also could be blamed on my sorry excuse for documentation. (Working on it.)