Forum PHP 2017

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.
  • 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 7 notes

ky dot patterson at adlinkr dot com
2 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:
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.
4 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:
function isohtmlspecialchars( $str ){
htmlspecialchars ( $str , ENT_COMPAT | ENT_HTML401 , 'ISO-8859-1' );
anton at zebooka dot com
3 years ago
It seems that starting of PHP 5.4 you can not override class method with different signature.

class A
    public function
doSomething($a, $b)

B extends A
    public function

PHP Strict standards:  Declaration of B::doSomething() should be compatible with A::doSomething(B $a) in Command line code on line 1
contact at nouslisons dot com
2 years ago
Be careful, in php 5.4. \e in string mean the escape character !
So you will have error for windows path:
$a = "c:\extend\toto.txt";

AND for date function:
echo date ("\t\h\e dmy");
you will have an escape character in your source instead "e"

The workaround I found is simple quote:
echo date ('\t\h\e dmy');
the dot mail dot bg at gmail dot com
3 years ago
There should be samples given here. There are many ways to do such coversion:

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".
luis at portanel dot com
4 years ago
It's not a PHP version incompatibility itself, but it's important to know that Microsoft dropped the php_mssql.dll support for the "mssql_" funcitions since this version.

To connect to a MSSQL database since 5.4, one good alternative are the PDO drivers.
blagdan at gmail dot com
3 years ago
'<?if'... worked in 5.3 as equivalent of '<?php if'... In 5.4 it's converted to '<!--?if'...
To Top