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' );
}
?>
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. - The register_globals and register_long_arrays php.ini directives have been removed.
- 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 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().
Chris ¶
5 months ago
luis at portanel dot com ¶
3 months 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.
