Handling Support Requests in the Support Forums

Posted by iWisdom in Support with the tags on October 16th, 2008

As anyone who has spent a decent amount of time in and around the support forums knows, there are an endless amount of questions being asked, and very few people who take the time to answer them (a big thanks to those of you who do!) Because of this, the time any of us can spend there is very much worth its weight in gold. Many of us (myself included) start developing certain methodologies we use when handling support requests in order to quickly and efficiently solve the problem before us. Here’s how I do it.

Step 1. Gather Information

Many of the issues currently faced within the support forums are recurring — they’re fairly common, and there are certain things that can lead one into recognizing them. For example, since the release of 3.0.2, some users receive this error message:

Code: Select all
SQL ERROR [ mysql4 ]

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'AND user_id = 11' at line 4 [1064]


SELECT notify_status FROM phpbb_topics_watch WHERE topic_id = AND user_id = 11


FILE: includes/db/mysql.php
LINE: 158
CALL: dbal->sql_error()

FILE: includes/functions_display.php
LINE: 1003
CALL: dbal_mysql->sql_query()

FILE: viewtopic.php
LINE: 456
CALL: watch_topic_forum()

As this is a somewhat common issue, I’m going to use it for the rest of our examples. Now, in this case, once seeing the error, my first question is “Did they recently update from 3.0.1?” To easily gather this information (and other information that often proves useful), the Support Team has posted a Support Request Template (SRT). If I’m looking for further information I will generally respond with the prompt at the bottom of the template, asking the user to complete it. Once the user has, we’re able to move on further.

Step 2. Identifying the Problem

In most cases, the SRT will provide enough information to solve the issue. Once it’s been completed, we should be presented with a nice set of information resembling this:

Your board’s URL:
Version of phpBB3: 3.0.2
Was this a fresh install or a(n) update/upgrade/conversion (please be specific)? 3.0.1 to 3.0.2
Did you use an automated wizard provided by your host to install phpBB? no
MODs you have installed: Quick Reply, ACP Add User, RedBar3
When the problem started: after I updated

Your level of expertise (be honest): novice

Additionally, you may wish to provide the following (where applicable)
Template(s) used: proSilver
Language(s) used: English
Version of PHP used: PHP 5.2.6
Database and version used: MySQL 5

As I mentioned earlier, this is a fairly common issue that is typically caused by an update from 3.0.1 to 3.0.2. As our SRT states that the user did indeed update from 3.0.1 to 3.0.2, we can identify this as the cause.

Step 3. Finding The Solution

In the case of a situation as per above where the problem is common, simple memorization is often the quickest course of action in presenting the solution. To do this, one need only spend a little time in the support forums reading solved threads — common issues appear often, and are often answered by the same answer (a future blog post will address what issues are “common”). Otherwise, the search tool is your best friend.

In this case, we’re going to assume that we don’t know the answer to the problem off the top of our heads. The next best step, then, is to plug this into a searching mechanism. For SQL errors like this, I’ll generally weed out any site-specific information (like the user ID in our SQL query), and search for the query with’s site search. We’ll then end up with a result list like this one. From here, we’ll find that the suggested solution is to replace includes/functions_display.php with a stock copy.

Step 4. Follow-Up

After providing a solution, I make a point of returning to the topic within a few hours to see if the user has tried the suggested solution. In the event that the solution works, I try to make a mental note of the problem and the answer in the event I encounter it again.

Note that my way of tacking problems is by no means the only way, and that you’ll very likely develop your own in a very short amount of time. So, go forth — see you in the support forums!

What If I Don’t Know The Answer?

There comes a time where all of us will encounter topics where we simply have no clue. If this is the case, your best bet is to simply move on. In many cases, an incorrect answer can cause more damage than not answering at all. If you’re unsure of your answer, it’s best to simply mark the topic in some way (I use the topic bookmarking feature for this) to return to it after a solution is provided — if the solution is the same as the one you had in mind, make a mental note of this for future support requests. Keep in mind that the support forum is as much a place for learning as it is problem solving, and while your intentions may be good in attempting to answer a question you are unsure of, sometimes the damage that can happen as a result is not ;)

4 Responses to “Handling Support Requests in the Support Forums”

Posted by ChrisRLG on October 16th, 2008 at 8:59 am:

Great post.

I tend to keep some ‘DRAFT’ posts (go to create a new topic and use the ‘save’ option instead of posting) for use of canned posts to standard problems. Then have a second window open with those draft posts so I can copy/paste the answer to any person with ‘that’ same problem.

Posted by mrgtb on October 20th, 2008 at 5:52 pm:

I agree, it is better for people not to post answers if they are unsure of the answer. As it can lead to people making changes that are not correct.

EDIT: Link removed – Highway
[ ]

Posted by Aby on November 19th, 2008 at 4:54 am:

Yes.. u r right. it will confuse us more.

Posted by H Lindsey on December 27th, 2008 at 3:10 am:

I’m runnig a forum and I remember that I used to beleive that I had to have an answer to all questions, big mistake, I’m not doing that anymore.

Commenting is disabled for this blog post