When debugging a site that's live, viewing the progression of your script can save quite a bit of time, resulting in considerably less complaints. However, it's absolutely essential that you avoid throwing your variables to the screen while visitors are viewing your pages. One way to avoid exposing your sensitive data, while also giving yourself a live printout of your variables is by making them visible to only you and/or your team.
The technique I will show you here requires that you have a static IP, or that you are willing to monitor your dynamic IP and change values as it changes. Also, everything that is echoed to the screen will be visible to anyone on your IP. So, if you are sharing IPs with someone you don't want viewing your data, this is not the technique you should use. This should also not be used for extremely sensitive data. If you think that it's worth someone's time spoofing your address, then avoid this at all costs. However, if your code is strictly for handling your grocery list, and you don't mind coming home with 100 extra cans of Minestrone, only to find that your wife didn't enter them, this might be optimal for you.
Another very important thing to remember: never leave debugging on any longer than you have to. Once you've completed your mission, be sure to turn it off. This will help to minimize the chances of someone grabbing your data while you aren't looking.

Initial Stuphs

First, you'll need to know your IP address. This can easily be determined by adding the following code to a test file:

<?php
echo $_SERVER['REMOTE_ADDR'];
?>
The address that's printed to the screen will be your very own internet address.
I prefer to use a prepended file on each of my sites, to cut down on the amount of code and also better my chances that the code will be cached. This can be set in your php.ini file under the value: auto_prepend_file. Anything that is common for every page on your site, and can be used before the file is loaded, goes into this file. Of course you are free to add the code in any file you'd like.

Checking For Safe Debugging

In my prepend file, or at the top of an example file, I add the following lines of code.

<?php

/* start with debugging off */
$debug 0;

/* an array containing a list of IPs that may view your data. */
$debug_ips = array('192.168.0.2');

/* make sure debugging is off to avoid it being set in the url */
$debug_ok 0;

/* determine if it's ok to throw errors to the screen */
if ( $debug == && in_array$_SERVER['REMOTE_ADDR'], $debug_ips ) )
    
$debug_ok 1;

?>
The above snippet verifies that it's ok to send debugging information to the browser. We have two basic requirements: the IP is in the $debug_ips array and debug is turned on (that is: $debug is set to '1'). By setting this early on and using a single variable, $debug_ok, throughout the site we can change the requirements at any time and not have to edit anything other than this data.
If you'd like to add someone to your list of people allowed to see the data, just add their IP to the $debug_ips array.
Moving on, lets say we have a form that's not working correctly. For some reason the data isn't making it to the database when the user hits submit. Once we've determined that the database is fine, we will need to check our variables. In order to print these variables to the screen, we will test first that it's ok, and if so we'll use a print_r on the form data.

<?php

/* test that debugging is ok and then print the variables */
if ( $debug_ok == print_r$_POST );

?>
The above code should be placed within the target page, where you want the data to appear. This will send all the values submitted via form, to the screen. Note: if you're using the GET method in the form, you'll want to use $_GET in your print_r() function.
Another great way to use this is for echoing your SQL query, rather than sending it to the database:

<?php

$sql 
"INSERT INTO wherever (field1,field2) VALUES ('$field1','$field2')";
if ( 
$debug_ok == ) echo $sql;
else 
mysql_query$sql );

?>
This will help avoid a database cleanup once you're finished debugging. Of course, you can use both of the debug snippets simultaneously to get the maximum effect.
If you prefer to recieve the data via email, you can always build your message throughout the script and at the end, use the mail() function:

<?php

if ( $debug_ok == mail'eggie@domain.com''It\'s broke!!!'$message );

?>
Doing things this way will also prevent the risk of accidentally sending your data to the wrong browsers.
If you prefer to log your data, you can do:

<?php

if ( $debug_ok == trigger_error'Your debug data here' );

?>
This requires that you have logging set up on the server. You can find more info on logging here.
There are many other options available to you. The above code leaves a lot of room for customizing. For instance, if you want to view only SQL data, you can assign $debug_ok a value of '2' and if $debug_ok == 2 then show the SQL data.

Summary

It's never a good idea to allow your errors to be viewed by the masses. By coding in your debug requirements early on, you will cut down on the amount of time it takes to debug your code. Of course, each time you add code to your site, you're slowing it down a little at a time. So, it's imperitive that you think out your debug strategy far in advance, using as little code as possible to get the most specific amount of data.