Backward Incompatible Changes

Although most existing PHP 5 code should work without changes, please take note of some backward incompatible changes:

  • Safe mode is no longer supported. Any applications that rely on safe mode may need adjustment, in terms of security.
  • Magic quotes has been removed. Applications relying on this feature may need to be updated, to avoid security issues. get_magic_quotes_gpc() and get_magic_quotes_runtime() now always return FALSE. set_magic_quotes_runtime() raises an E_CORE_ERROR level error on trying to enable Magic quotes.
  • The register_globals and register_long_arrays php.ini directives have been removed.
  • The mbstring.script_encoding directive has been removed. Use zend.script_encoding instead.
  • Call-time pass by reference has been removed.
  • The break and continue statements no longer accept variable arguments (e.g., break 1 + foo() * $bar;). Static arguments still work, such as break 2;. As a side effect of this change break 0; and continue 0; are no longer allowed.
  • The default character set for htmlspecialchars(), htmlentities() and html_entity_decode() is now UTF-8, instead of ISO-8859-1. Note that changing your output charset via the default_charset configuration setting does not affect htmlspecialchars/htmlentities unless you are passing "" (an empty string) as the encoding parameter to your htmlspecialchars()/htmlentities()/html_entity_decode() calls. Generally we do not recommend doing this because you should be able to change your output charset without affecting the runtime charset used by these functions. The safest approach is to explicitly set the charset on each call to htmlspecialchars(), htmlentities() and html_entity_decode().
  • In the date and time extension, the timezone can no longer be set using the TZ environment variable. Instead you have to specify a timezone using the date.timezone php.ini option or date_default_timezone_set() function. PHP will no longer attempt to guess the timezone, and will instead fall back to "UTC" and issue a E_WARNING.
  • Non-numeric string offsets - e.g. $a['foo'] where $a is a string - now return false on isset() and true on empty(), and produce a E_WARNING if you try to use them. Offsets of types double, bool and null produce a E_NOTICE. Numeric strings (e.g. $a['2']) still work as before. Note that offsets like '12.3' and '5 foobar' are considered non-numeric and produce a E_WARNING, but are converted to 12 and 5 respectively, for backward compatibility reasons. Note: Following code returns different result. $str='abc';var_dump(isset($str['x'])); // false for PHP 5.4 or later, but true for 5.3 or less
  • Converting an array to a string will now generate an E_NOTICE level error, but the result of the cast will still be the string "Array".
  • Turning NULL, FALSE, or an empty string into an object by adding a property will now emit an E_WARNING level error, instead of E_STRICT.
  • Parameter names that shadow super globals now cause a fatal error. This prohibits code like function foo($_GET, $_POST) {}.
  • The Salsa10 and Salsa20 hash algorithms have been removed.
  • The Tiger hash algorithm now uses big-endian byte ordering. Please follow this example to write code that is compatible with both PHP 5.3 and 5.4.
  • array_combine() now returns array() instead of FALSE when two empty arrays are provided as parameters.
  • If you use htmlentities() with asian character sets, it works like htmlspecialchars() - this has always been the case in previous versions of PHP, but now an E_STRICT level error is emitted.
  • The third parameter of ob_start() has changed from boolean erase to integer flags. Note that code that explicitly set erase to FALSE will no longer behave as expected in PHP 5.4: please follow this example to write code that is compatible with PHP 5.3 and 5.4.

The following keywords are now reserved, and may not be used as names by functions, classes, etc.

The following functions have been removed from PHP:

add a note add a note

User Contributed Notes 3 notes

up
40
ky dot patterson at adlinkr dot com
10 years ago
If you have content that is not 100% UTF-8 then TAKE NOTE:

Starting in PHP 5.4 htmlspecialchars() and htmlentities() assume charset=UTF-8 by default AND WILL RETURN BLANK IF YOUR INPUT IS NOT VALID UTF-8.

So if you have a lot of function calls that look like this:
<?php
echo htmlspecialchars($input);
// or
echo htmlentities($input);
?>
i.e. no charset and no flags -- and $input is ISO-8859 (or anything else apart from 7-bit ASCII or UTF-8) -- then PHP 5.4 and 5.5 will return an empty string, and you will be surprised and probably unhappy.

This is apparently a feature, not a bug.
up
30
Chris
11 years ago
Missing some chars like german umlauts after use of htmlspecialchars? That's because the third param encoding has changed it's default value in PHP 5.4 from ISO-8859-1 to UTF-8.

Possible solution #1:
Change your code from this ...
<?php htmlspecialchars( 'äöü' ); ?>
... to this:
<?php htmlspecialchars ( 'äöü' , ENT_COMPAT | ENT_HTML401 , 'ISO-8859-1' ); ?>

Possible solution #2:
Create a wrapper function and replace htmlspecialchars( to i.e. isohtmlspecialchars( with your IDE/editor/shell...

Example of a wrapper function:
<?php
function isohtmlspecialchars( $str ){
   return
htmlspecialchars ( $str , ENT_COMPAT | ENT_HTML401 , 'ISO-8859-1' );
}
?>
up
20
anton at zebooka dot com
11 years ago
It seems that starting of PHP 5.4 you can not override class method with different signature.

Example:
<?php
class A
{
    public function
doSomething($a, $b)
    {
    }
}

class
B extends A
{
    public function
doSomething($c)
    {
    }
}
?>

PHP Strict standards:  Declaration of B::doSomething() should be compatible with A::doSomething(B $a) in Command line code on line 1
To Top