Support Requests: Some Thoughts

I recently took a management class in which we studied a lesson on dealing with upper managment and when to escalate issues. One of the key points when you escalate an issue to a management level higher than your immediate one is to have at least one possible solution for the problem you present.
Assuming that you’re a thinking being and you know what you want, I don’t think it’s too hard to offer these ideas with your support requests. There have been a couple of issues over the past weeks wherein people say “X doesn’t work” and don’t bother mentioning what they tried to do to solve it. I can imagine that not everyone is as technically inclined as me or others, but a little common sense can go a long way.
One way to add a bit of sense to what you’re doing is to log the -f- in. I can’t talk to you if you’re anonymous. If you’ve got an account, attach your site to the account so that we can look at it and your issues. If the site in your profile is not the site with problems, post a link to the problem site. Imagine how much more quickly you can get things working if we don’t have to bounce back and forth asking you for the site URL, etc. etc. ad infinitum.
Know what your server permissions and capabilities are. I know that a lot of you are server novices, and that’s ok – I’m hoping to educate you a little here. You may be asked what permissions you have and can set on your server. Note that the permission you have to write to your site via FTP can be very different from the permission your web server has to write files to the same place. You’ll probably need to mention whether your site runs on Windows, Linux, or some other strange platform.
You might also need to know your PHP version and what extensions are installed. This is easy to learn. Create a file named phpinfo.php in your web root directory. In it, put this code:
<?php phpinfo(); ?>
Accessing this file through your web server will produce a ton of information that is useful for anyone trying to help you with your code issues.
If you don’t have a copy of phpMyAdmin on your server, you probably should. This software lets you access the raw data in your database (where the WordPress posts aer stored) without using WordPress or a shell login. With it, you can produce dumps of the data in your database that might be needed for debugging a feature or plugin. Using phpMyAdmin can also provide a convenient way to backup your WordPress posts.
You should probably know where the validators are, too. Validators process your web page and tell if there is a tag missing or if an attribute is incorrectly specified. It’s your first method of detection when something isn’t displaying as you expect in your browser. In fact, I might go so far as to say this: Don’t post a message saying “my entire sidebar has vanished in IE but not Mozilla” (or the like) without first running your page through a validator.
An HTML validator is here. A CSS validator is here. Personally, I browse with FireFox and use the web developer extension, which has options to automatically validate the current page. This tool is also great for debugging CSS issues because it shows you the changes as you edit the CSS in real time.
You should also know where the WordPress resources are. There is a lot of information on the WordPress Wiki. There, you can find some answers for “How Do I…?” and “What does … do?” and “Is there a plugin that…?” and avoid having to wait for the inevitable link to https://wiki.www.ads-software.com/Plugin where a list of plugins is maintained.
Another simple thing to note is what version of WordPress you are using. In case you didn’t know, you can find a file in the wp-includes directory called “version.php” that contains the version info. This is useful to know in case you’ve deleted that info from everywhere else that it might appear.
Sometimes just the error report is enough for a developer to solve the issue, but more often than not, it’s user error. Most times, a developer can’t ask what is on his mind (“What did you do to screw up my beautiful code?”), and must resort to a list of possibilities (“Did you change X? Did you fiddle with Y?”). Noting any changes that you made that might affect the problem could save a lot of time.
Use common sense here, too. If the script you’re running writes files to the server, be sure to note in your request the permissions of the server used to write those files. If the script you’re running requires a specific CSS file, check that the CSS file is included in the page source that is sent to your browser.
If you’ve researched everything here, it’s very likely that you can solve your own problem, or at least phrase a question that will induce a direct answer rather than a series of questions in response.
I really haven’t met anyone in this forum that wasn’t willing to give civil, courteous help. Help them out by first evaluating the problem yourself as much as you can, and then reporting both the behavior that you want and the relevant details of your problem and environment. Everyone will benefit from it.