The debugger protocol is line-based. Each line has a type, and several lines compose a message. Each message starts with a line of the type start and terminates with a line of the type end. PHP may send lines for different messages simultaneously. A line has this format: date time host(pid) type: message-data date Date in ISO 8601 format (yyyy-mm-dd) time Time

PHP’s internal debugger is useful for tracking down evasive bugs. The debugger works by connecting to a TCP port for every time PHP starts up. All error messages from that request will be sent to this TCP connection. This information is intended for “debugging server” that can run inside an IDE or programmable editor (such as Emacs). How to set up the debugger: Set

The PHP 3.0 Apache module no longer supports Apache versions prior to 1.2. Apache 1.2 or later is required. echo() no longer supports a format string. Use the printf() function instead. In PHP/FI 2.0, an implementation side-effect caused $foo[0] to have the same effect as $foo. This is not true for PHP 3.0. Reading arrays with $array[] is no longer supported That

Most internal functions have been rewritten so they return TRUE when successful and FALSE when failing, as opposed to 0 and -1 in PHP/FI 2.0, respectively. The new behaviour allows for more logical code, like $fp = fopen("/your/file") or fail("darn!");. Because PHP/FI 2.0 had no clear rules for what functions should return when they failed, most such scripts will probably have

In PHP 3.0 boolean evaluation is short-circuited. This means that in an expression like (1 || test_me()), the function test_me() would not be executed since nothing can change the result of the expression after the 1. This is a minor compatibility issue, but may cause unexpected side-effects.

PHP 3.0’s error messages are usually more accurate than 2.0’s were, but you no longer get to see the code fragment causing the error. You will be supplied with a file name and a line number for the error, though.

PHP/FI 2.0 used the left side of expressions to determine what type the result should be. PHP 3.0 takes both sides into account when determining result types, and this may cause 2.0 scripts to behave unexpectedly in 3.0. Consider this example: $a[0]=5; $a[1]=7; $key = key($a); while ("" != $key) { echo "$keyn"; next($a); } In PHP/FI 2.0, this would display both of $a’s

Just like with if..endif, the syntax of while..endwhile has changed as well: Example A-7. Migration: old while..endwhile syntax while ($more_to_come); ... endwhile; Example A-8. Migration: new while..endwhile syntax while ($more_to_come): ... endwhile; Warning If you use the old while..endwhile syntax in PHP 3.0, you will get a never-ending

The `alternative’ way to write if/elseif/else statements, using if(); elseif(); else; endif; cannot be efficiently implemented without adding a large amount of complexity to the 3.0 parser. Because of this, the syntax has been changed: Example A-5. Migration: old if..endif syntax if ($foo); echo "yep\n"; elseif ($bar); echo "almost\n"; else; echo "nope\n"; endif; Example

The first thing you probably will notice is that PHP’s start and end tags have changed. The old <? > form has been replaced by three new possible forms: Example A-1. Migration: old start/end tags <? echo "This is PHP/FI 2.0 code.\n"; > As of version 2.0, PHP/FI also supports this variation: Example A-2. Migration: first new start/end tags <? echo