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 anE_CORE_ERRORlevel error on trying to enable Magic quotes. - The register_globals and register_long_arrays php.ini directives have been removed.
- mbstring.script_encoding directives have 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_WARNINGif you try to use them. Offsets of types double, bool and null produce aE_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 aE_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_NOTICElevel 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 anE_WARNINGlevel error, instead ofE_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.
-
array_combine() now returns array() instead of
FALSEwhen 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_STRICTlevel error is emitted. -
The third parameter of ob_start() has changed from
boolean
eraseto integerflags. Note that code that explicitly seterasetoFALSEwill 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:
- define_syslog_variables()
- import_request_variables()
- session_is_registered(), session_register() and session_unregister().
- The aliases mysqli_bind_param(), mysqli_bind_result(), mysqli_client_encoding(), mysqli_fetch(), mysqli_param_count(), mysqli_get_metadata(), mysqli_send_long_data(), mysqli::client_encoding() and mysqli_stmt::stmt().
- Что изменилось в PHP 5.4.x?
- Обратно несовместимые изменения
- Новые возможности
- Изменения в модулях SAPI
- Устаревшие функции и возможности в PHP 5.4.x
- Измененные функции
- Новые функции
- Новые классы и интерфейсы
- Новые методы
- Удаленные расширения
- Другие изменения в расширениях
- Новые глобальные константы
- Изменения в обработке INI-файлов
- Другие изменения
Коментарии
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' );
}
?>
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
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.