homepage Welcome to WebmasterWorld Guest from
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member
Home / Forums Index / Code, Content, and Presentation / PHP Server Side Scripting
Forum Library, Charter, Moderators: coopster & jatar k

PHP Server Side Scripting Forum


 4:07 pm on Jan 14, 2004 (gmt 0)

In another thread, while I was helping someone work through an example of dynamic nav, I thought it would be good to mention a couple of things that I do when the code I'm working on goes sideways (breaks). SO...

I build PHP applications in chunks. Partly because I'm not an Uber Geek and partly because it helps in trouble-shooting. I build my apps in logical progressions so that I can test each stage for accuracy, security, speed, as well as whether or not is works. If something does get messed up I tend to use the following rules of thumb.

Is there an error message?
On items like queries to a MySQL database I add

or die("An error occurred in the descriptive name for the query so I know which one choked: ".mysql_error())

This will spit out the error for that query. It helps in getting rid of syntax errors like quotes.

Did the vars get passed?
For code where I'm passing vars on the URL I will place echos at the top of the receiving page to determine whether the var made it. If you're using a link to pass the vars you can accomplish the same thing by simply holding your pointer over the link - the URL should appear.

Is it the function or what I do with the results of the function?
For functions I sometimes bring the code of the function into the file I'm working with and comment out the call to the function. I'll work with the variables until I figure out what I did wrong and then move that code back to the function's file (usually an include of somesort).

You mean that's supposed to loop?
For loops that don't give me the right number of outputs I will test the control.


is what I often use for outputs from multiple record queries. I will echo $num_rows to determine how many it sees. I know what it should be because I use PHPMyAdmin to view the table and/or run a SQL query to get the same results. If the number is right then what I do with the results is broken. If not - then I'm back to the query.

It's supposed to be Jan. 14, 2004 not December 31, 1969
For conversions I often will see if I can at least get an output of somesort. Date's often trip people up - me too - even now. Simple formatting errors are what often get me. Sometimes I use the MySQL formatting to circumvent having to do it in PHP. Other times I simply use PHP's date() function.

Other tips for troubleshooting?



 4:24 pm on Jan 14, 2004 (gmt 0)

print_r [ca.php.net] is your friend

For printing arrays and objects which can be difficult or confusing. This is something I was using recently for some testing.

echo "<p>This is the set of environment vars";
echo "<p><pre>";
echo "</pre>";

echo "<p>This is the set of cookie vars";
echo "<p><pre>";
echo "</pre>";

echo "<p>This is the set of session vars";
echo "<p><pre>";
echo "</pre>";

The pre tags make it browser readable instead of having to view source. Otherwise you get a nice big blob.


 4:50 pm on Jan 14, 2004 (gmt 0)


Note: This differs from the offering by lorax in that sometimes the query 
will execute without an error, but return unexpected results.

Here is how I tend to troubleshoot SQL statements. First, use a variable to contain the entire SQL statement. Then, right before you execute the statement, exit the code and print the query statement to the screen -- odds are you will be able to spot your issues quite quickly:

$sql = "SELECT * FROM table WHERE table.key1 = '$key_variable'";
//exit($sql); // Uncomment this line for troubleshooting!
$result = mysql_query($sql);

Then if you feel you have it correct, you can cut and paste it to a MySQL command line interface and try to run it. MySQL will give you the results or tell you where the issue starts.


 5:00 pm on Jan 14, 2004 (gmt 0)

I build my apps in logical progressions so that I can test each stage for accuracy, security, ...

I'm curious, how do you test for security?


 5:06 pm on Jan 14, 2004 (gmt 0)

>> I'm curious, how do you test for security?

There are two levels that I tend to focus on. One is the server level - usually I test for latest MySQL patches by testing for some of the more recent MySQL hacks.

The second level involves user input - forms and URL vars. I will see if I can break my own code by filling in form fields with characters that are typcially no-nos. I will also try to manually manipulate the URLs and pass vars on it to see if I can again break my scripts.

I have yet to automate this procedure and it's far from scientific. It's simply a way to beat up on the application to see if I've left any obvious holes.


 6:17 pm on Jan 14, 2004 (gmt 0)

Error Handling and Logging Functions
URL: [php.net...]

I like to have ALL errors reporting during development and testing. I often use two ways of doing so. Preference is to set an .htaccess file. If this is not an option use the PHP ini-set [php.net] or error_reporting [php.net] function:


# PHP < 5.0.0
php_value error_reporting 2047
# PHP > 5.0.0
# php_value error_reporting 4095

Note: I know the manual states that using named constants is strongly encouraged to ensure compatibility for future versions so go ahead and change them if PHP > 3.


# PHP < 5.0.0
ini_set('error_reporting', E_ALL);
# PHP > 5.0.0
ini_set('error_reporting', E_ALL ¦ E_STRICT);


# PHP < 5.0.0
# PHP > 5.0.0
error_reporting(E_ALL ¦ E_STRICT);

I think the PHP Manual [php.net] says it best:

error_reporting integer [php.net]

Set the error reporting level. The parameter is either an integer representing a bit field, or named constants. The error_reporting levels and constants are described in Predefined Constants [php.net], and in php.ini. To set at runtime, use the error_reporting() [php.net] function. See also the display_errors [php.net] directive.

In PHP 4 and PHP 5 the default value is E_ALL & ~E_NOTICE. This setting does not show E_NOTICE level errors. You may want to show them during development.

Note: Enabling E_NOTICE during development has some benefits. For debugging purposes: NOTICE messages will warn you about possible bugs in your code. For example, use of unassigned values is warned. It is extremely useful to find typos and to save time for debugging. NOTICE messages will warn you about bad style. For example, $arr[item] is better to be written as $arr['item'] since PHP tries to treat "item" as constant. If it is not a constant, PHP assumes it is a string index for the array.

Note: In PHP 5 a new error level E_STRICT is available. As E_STRICT is not included within E_ALL you have to explicitly enable this kind of error level. Enabling E_STRICT during development has some benefits. STRICT messages will help you to use the latest and greatest suggested method of coding, for example warn you about using deprecated functions.

In PHP 3, the default setting is (E_ERROR E_WARNING E_PARSE), meaning the same thing. Note, however, that since constants are not supported in PHP 3's php3.ini, the error_reporting setting there must be numeric; hence, it is 7.

[edited by: jatar_k at 7:30 pm (utc) on Mar. 1, 2004]
[edit reason] fixed typo [/edit]


 8:53 pm on Jan 14, 2004 (gmt 0)

Ah coopster - I knew I could count on you and jatar_k.

It's also worth pointing out that these tips are best used while working out the kinks from your code. If the code is ready to go public it is better to catch the errors and process them silently. In other words you don't want "Cannot connect to the database: Syntax error on line 32 '"annual = 2004-03-34"'" showing up all of the sudden. Handle the erros and have the code notify you.


 9:07 pm on Jan 14, 2004 (gmt 0)

great topic!

i've just set error_reporting(E_ALL); and am inundated with Undefined variables and properties.

most of these are variables which i do or do not use depending on the page generated.

is this a baad thing?



 9:41 pm on Jan 14, 2004 (gmt 0)

most of these are variables which i do or do not use depending on the page generated.

is this a baad thing?

With register_globals off, probably not, but is "probably" good enough?

Getting rid of these error messages and notices involves extra coding, but it does make you think through the "what ifs" much more thoroughly. For example, instead of

if ($var) {do stuff}

Now you have
if (isset($var) &&!empty($var)) { do stuff}

And you can't help but think "what is the "else" if $var isn't set?" Sure, you should think about this no matter what, but you really can't escape it when you decide to set error reporting to high and to eliminate all notices.


 8:29 am on Jan 15, 2004 (gmt 0)

thanks ergophobe,

i have been getting lazy with my if ($var) constructs. will recode a bit.

Global Options:
 top home search open messages active posts  

Home / Forums Index / Code, Content, and Presentation / PHP Server Side Scripting
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved