The Development Environment

The development environment is a place where the raw code is created without fear of server crashes or peer ridicule. This should be a place where concepts and theories are proven or disproven; where code can be created experimentally. Therefore, the error-reporting environmental feedback should be as verbose as possible. All error reporting should be logged and at the same time also sent to the output device (the browser). All warnings should be as sensitive and descriptive as possible.

The location of this development environment can be debated. However, if your company has the resources, then a separate server should be established for this purpose with full code management (e.g., SVN, a.k.a. Subversion, or Git) in place. If the resources are not available, then a development PC can serve this purpose via a localhost-style setup. This localhost environment can be advantageous in and of itself in the sense that you may want to try something completely off-the-wall, and by coding on a standalone PC you can be fully experimental without affecting a common development server or anyone else’s code base.

You can create localhost environments with the Apache web server, or Microsoft’s IIS, as a manual process. There are a few all-in-one environments that can be utilized as well; Zend Server CE (Community Edition) is a great example.

No matter what setup you have for raw development, be sure to give your developers full freedom to do what they want without fear of reprimand. This gives them the confidence to be as innovative as possible, and no one gets “hurt.”

The Staging Environment

The staging environment should mimic the production environment as closely as possible. Although this is sometimes hard to achieve, the more closely you can mimic the production environment, the better. You will be able to see how your code reacts in an area that is protected but also simulates the real production environment. The staging environment is often where the end user or client can test out new features or functionality, giving feedback and stress-testing code, without fear of affecting production code.

If resources permit, you should consider having two separate staging environments: one for developers (coding peers) and the other for client testing. Feedback from these two types of users is quite often very different and very telling. Server error reporting and feedback should be kept to a minimum here as well, to duplicate production as closely as possible.

The Production Environment

The production environment, from an error-reporting perspective, needs to be as tightly controlled as possible. You want to fully control what the end user sees and experiences. Things like SQL failures and code syntax warnings should never be seen by the client, if at all possible. Your code base, of course, should be well mitigated by this time (assuming you’ve been using the two aforementioned environments properly and religiously), but sometimes errors and bugs can still get through to production. If you’re going to fail in production, you want to fail as gracefully and as quietly as possible.

At the very least, all error reporting should be suppressed and sent to the logfiles in the production environment.

php.ini Settings

There are a few environment-wide settings to consider for each type of server you’re using to develop your code. First, we’ll offer a brief summary of what these are, and then we’ll list the recommended settings for each of the three coding environments.

display_errors

An on-off toggle that controls the display of any errors encountered by PHP. This should be set to 0 (off) for production environments.

error_reporting

This is a setting of predefined constants that will report to the error log and/or the web browser any errors that PHP encounters. There are 16 different individual constants that can be set within this directive, and certain ones can be used collectively. The most common ones are E_ALL, for reporting all errors and warnings of any kind; E_WARNING, for only showing warnings (nonfatal errors) to the browser; and E_DEPRECATED, to display runtime notice warnings about code that will fail in future versions of PHP because some functionality is scheduled to be ended (like register_globals was). An example of these being used in combination is E_ALL & ~E_NOTICE, which tells PHP to report all errors except the generated notices. A full listing of these defined constants can be found on the PHP website (http://www.php.net/manual/en/errorfunc.constants.php).

error_log

The path to the location of the error log. The error log is a text-based file located on the server at the path location that records all errors in text form. This could be apache2/logs in the case of an Apache server.

variables_order

Sets the order of precedence in which the superglobal arrays are loaded with information. The default order is EGPCS, meaning the environment ($_ENV) array is loaded first, then the GET ($_GET) array, then the POST ($_POST) array, then the cookie ($_COOKIE) array, and finally the server ($_SERVER) array.

request_order

Describes the order in which PHP registers GET, POST, and cookie variables into the $_REQUEST array. Registration is done from left to right, and newer values override older values.

zend.assertions

Determines whether assertions are run and throw errors. When disabled, the conditions in calls to assert() are never run (thus, any side effects they might have do not happen).

assert.exception

Determines whether the exception system is enabled. By default, this is on in both development and production environments, and is generally the preferred way to handle error conditions.

Additional settings can be used as well; for example, you can use ignore_repeated_errors if you are concerned with your logfile getting too large. This directive can suppress repeating errors being logged, but only from the same line of code in the same file. This could be useful if you are debugging a looping section of code and an error is occurring somewhere within it.

PHP also allows you to alter certain INI settings from their server-wide settings during the execution of your code. This can be a quick way to turn on some error reporting and display the results on screen, but it is still not recommended in a production environment. You could do this in the staging environment if desired. One example is to turn on all the error reporting and display any reported errors to the browser in a single suspect file. To do so, insert the following two commands at the top of the file:

error_reporting(E_ALL);
ini_set("display_errors", 1);

The error_reporting() function allows you to override the level of reported errors, and the ini_set() function allows you to change php.ini settings. Again, not all INI settings can be altered, so be sure to check the PHP website (http://ca.php.net/manual/en/ini.list.php) for what can and cannot be changed at runtime.

As promised earlier, Table 17-1 lists the PHP directives and their recommendations for each of the three basic server environments.

Error Handling

Error handling is an important part of any real-world application. PHP provides a number of mechanisms that you can use to handle errors, both during the development process and once your application is in a production environment.

(E_ERROR | E_PARSE | E_CORE_ERROR | E_COMPILE_ERROR | E_USER_ERROR)

(E_ALL & ~E_NOTICE)

try {
 $result = eval($code);
} catch {ParseException $exception) {
 // handle the exception
}

$value = @(2 / 0);

error_reporting(0);

assert (mixed $expression [, mixed $message]);

function divider($a, $b) {
 assert($b != 0, '$b cannot be 0');

 return($a / $b);
}

echo divider(200, 3);
echo divider(10, 0);
66.666666666667
Fatal error: $b cannot be 0 in page.php on line 5

class DividerParameterException extends AssertionException { }

function divider($a, $b) {
 assert($b != 0, new DividerParameterException('$b cannot be 0'));

 return($a / $b);
}

function displayError($error, $errorString, $filename, $line, $symbols)
{
 echo "<p>Error '<b>{$errorString}</b>' occurred.<br />";
 echo "-- in file '<i>{$filename}</i>', line $line.</p>";
}

set_error_handler('displayError');
$value = 4 / 0; // divide by zero error

<p>Error '<b>Division by zero</b>' occurred.
-- in file '<i>err-2.php</i>', line 8.</p>

error_log(message, type [, destination [, extra_headers ]]);

error_log('A connection to the database could not be opened.', 0);

error_log('A connection to the database could not be opened.',
 1, '[email protected]');

error_log('A connection to the database could not be opened.',
 3, '/var/log/php_errors.log');

function logRoller($error, $errorString) {
 $file = '/var/log/php_errors.log';

 if (filesize($file) > 1024) {
 rename($file, $file . (string) time());
 clearstatcache();
 }

 error_log($errorString, 3, $file);
}

set_error_handler('logRoller');

for ($i = 0; $i < 5000; $i++) {
 trigger_error(time() . ": Just an error, ma'am.
");
}

restore_error_handler();

display_errors = Off
log_errors = On
error_log = /tmp/errors.log

<html>
 <head>
 <title>Results!</title>
 </head>

 <body>
 <?php function handle_errors ($error, $message, $filename, $line) {
 ob_end_clean();
 echo "<b>{$message}</b><br/> in line {$line}<br/> of ";
 echo "<i>{$filename}</i></body></html>";

 exit;
 }

 set_error_handler('handle_errors');
 ob_start(); ?>

 <h1>Results!</h1>

 <p>Here are the results of your search:</p>

 <table border="1">
 <?php require_once('DB.php');
 $db = DB::connect('mysql://gnat:waldus@localhost/webdb');

 if (DB::iserror($db)) {
 die($db->getMessage());
 } ?>
 </table>
 </body>
</html>

Manual Debugging

Once you get a few good years of development time under your belt, you should be able to get at least 75% of your debugging done on a purely visual basis. What of the other 25%, and the more difficult segments of code that you need to work through? You can tackle some of it by using a great code development environment like Zend Studio for Eclipse or Komodo. These advanced IDEs can help with syntax checking and some simple logical problems and warnings.

You can do the next level of debugging (again, you’ll do most of this in the development environment) by echoing values out onto the screen. This will catch a lot of logic errors that may be dependent on the contents of variables. For example, how would you be able to easily see the value of the third iteration of a for...next loop? Consider the following code:

for ($j = 0; $j < 10; $j++) {
 $sample[] = $j * 12;
}

The easiest way is to interrupt the loop conditionally and echo out the value at the time; alternatively, you can wait until the loop is completed, as in this case since the loop is building an array. Here are some examples of how to determine that third iteration value (remember that array keys start with 0):

for ($j = 0; $j < 10; $j++) {
 $sample[] = $j * 12;

 if ($j == 2) {
 echo $sample[2];
 }
}
24

Here we are simply inserting a test (if statement) that will send a particular value to the browser when that condition is met. If you are having SQL syntax problems or failures, you can also echo the raw statement out to the browser and copy it into the SQL interface (phpMyAdmin, for example) and execute the code that way to see if any SQL error messages are returned.

If we want to see the entire array at the end of this loop, and what values it contains in each of its elements, we can still use the echo statement, but it would be tedious and cumbersome to write echo statements for each one. Rather, we can use the var_dump() function. The extra advantage of var_dump() is that it also tells us the data type of each element of the array. The output is not necessarily pretty, but it is informative. You can copy the output into a text editor and use it to clean up the look of the output.

Of course you can use echo and var_dump() in concert as the need arises. Here is an example of the raw var_dump() output:

for ($j = 0; $j < 10; $j++) {
 $sample[] = $j * 12;
}

var_dump($sample);
array(10) { [0] => int(0) [1] => int(12) [2] => int(24) [3] => int(36) [4] => int(48) [5] =>
int(60) [6] => int(72) [7] => int(84) [8] => int(96) [9] => int(108)}

<?php
for ($j = 0; $j < 10; $j++) {
 $sample[] = $j * 12;
}
?>
<pre><?php print_r($sample); ?></pre>

Array( [0] => 0 [1] => 12 [2] => 24 [3] => 36 [4] => 48 [5] => 60
[6] => 72 [7] => 84 [8] => 96 [9] => 108)

Error Logs

You will find many helpful descriptions in the error logfile. As mentioned previously, you should be able to locate the file under the web server’s installation folder in a folder called logs. You should make it part of your debugging routine to check this file for helpful clues as to what might be amiss. Here is just a sample of the verbosity of an error logfile:

[20-Apr-2012 15:10:55] PHP Notice: Undefined variable: size in C:Program Files (x86)
[20-Apr-2012 15:10:55] PHP Notice: Undefined index: p in C:Program Files (x86)end
[20-Apr-2012 15:10:55] PHP Warning: number_format() expects parameter 1 to be double
[20-Apr-2012 15:10:55] PHP Warning: number_format() expects parameter 1 to be double
[20-Apr-2012 15:10:55] PHP Deprecated: Function split() is deprecated in C:Program
[20-Apr-2012 15:10:55] PHP Deprecated: Function split() is deprecated in C:Program
[26-Apr-2012 13:18:38] PHP Fatal error: Maximum execution time of 30 seconds exceeded

As you can see, there are a few different types of errors being reported here—notices, warnings, deprecation notices, and a fatal error—with their respective timestamps, file locations, and the line on which the error occurred.

IDE Debugging

For more complex debugging issues, you would be best served to use a debugger that can be found in a good integrated development environment (IDE). We will be showing you a debug session example with Zend Studio for Eclipse. Other IDEs, like Komodo and PhpED, have built-in debuggers, so they can also be used for this purpose.

Zend Studio has an entire Debug Perspective set up for debugging purposes, as shown in Figure 17-1.

Figure 17-1. The default Debug Perspective in Zend Studio

To get your bearings with this debugger, open the Run menu. It shows all the options you can try when in the debug process—stepping into and over code segments, running to a cursor location, restarting the session from the beginning, and just simply letting your code run until it fails or ends, to name a few.

Check the many debug views in this product as well; you can watch the variables (both superglobals and user-defined) as they change over the course of code execution.

Breakpoints can also be set (and suspended) anywhere in the PHP code, so you can run to a certain location in your code and view the overall situation at that particular moment. Two other handy views are Debug Output and Browser Output, which present the output of the code as the debugger runs through it. The Debug Output view presents the output in the format you would see if you had selected View Source in a browser, showing the raw HTML as it is being generated. The Browser Output view displays the executing code as it would appear in a browser. The neat thing about both of these views is that they’re populated as the code executes, so if you are stopped at a breakpoint halfway through your code file, they display only the information generated up to that point.

Figure 17-2 shows an example of the sample code from earlier in this chapter (with an added echo statement within the for loop so that you can see the output as it is being created) run in the debugger. The two main variables ($j and $sample) are being tracked in the Expressions view, and the Browser Output and Debug Output views display their content at a stopped location in the code.

Figure 17-2. The debugger in action with watch expressions defined

Additional Debugging Techniques

There are more advanced techniques that can be used for debugging, but they are beyond the scope of this chapter. Two such techniques are profiling and unit testing. If you have a large web system that requires a lot of server resources, you should certainly look into the benefits of these two techniques, as they can make your code base more fault-tolerant and efficient.

What’s Next

Up next, we’ll explore writing Unix and Windows cross-platform scripts, and provide a brief introduction to hosting your PHP sites on Windows servers.