PHP: Évolutions incompatibles avec les versions précédentes

Évolutions incompatibles avec les versions précédentes

Même si l'essentiel du code PHP 5 devrait fonctionner sans modification, il faut faire attention aux situations suivantes, qui sont incompatibles avec les versions précédentes :

Safe mode n'est plus supporté. Toute application se reposant sur ce paramètre devra être revue, notamment en termes de sécurité.
Magic quotes ont été supprimées. Toute application se reposant sur ce paramètre devra être revue, notamment en termes de sécurité. get_magic_quotes_gpc() et get_magic_quotes_runtime() retournent désormais toujours FALSE. set_magic_quotes_runtime() lève une erreur E_CORE_ERROR lorsque vous tentez d'activer les guillemets magiques.
Les directives du php.ini register_globals et register_long_arrays ont été supprimées.
mbstring.script_encoding directives a été retiré. Préférez zend.script_encoding à la place.
Call-time pass by reference a été supprimé.
Les instructions break et continue n'acceptent plus de paramètre variable (exemple: break 1 + foo() * $bar;). Les arguments statiques fonctionnent toujours, par exemple break 2;. Un effet de bord de cette modification est que break 0; et continue 0; ne sont plus autorisés.
Le jeu de caractères par défaut pour htmlspecialchars() htmlentities() et html_entity_decode() est désormais UTF-8, au lieu de ISO-8859-1. Notez que modifier votre jeu de caractères de sortie via l'option de configuration default_charset n'affecte pas les fonctions htmlspecialchars/htmlentities, à moins que ne vous passiez "" (une chaîne vide) comme argument d'encodage lors de vos appels aux fonctions htmlspecialchars()/htmlentities() /html_entity_decode(). Généralement, nous ne vous recommandons pas de faire ceci, car vous devriez pouvoir modifier le jeu de caractères de sortie sans affecter le jeu de caractères utilisé par ces fonctions. L'approche la plus sûre est de définir explicitement le jeu de caractères lors de chaque appel aux fonctions htmlspecialchars(), htmlentities() et html_entity_decode().
Dans l'extension Date et Heure, le fuseau ne peut plus être défini au moyen de la variable d'environnement TZ. Vous devez préciser un fuseau horaire en utilisant l'option de php.ini date.timezone ou la fonction date_default_timezone_set(). PHP n'essayera plus de deviner le fuseau horaire et utilisera par défaut "UTC" tout en émettant une alerte de niveau E_WARNING.
Les index de tableaux non numériques concernant les chaines - exemple: $a['foo'] où $a est une chaine - retournent maintenant false sur un isset() et true sur un empty(), et produisent une alerte de niveau E_WARNING si vous les utilisez. Les index de type flottant, bool et null produisent une alerte de niveau E_NOTICE. Les index de type chaine numérique (exemple: $a['2']) fonctionnent comme avant. Notez que les index tels que '12.3' et '5 foobar' sont considérés comme non-numériques et produisent une alerte de niveau E_WARNING, mais sont convertis vers 12 et 5 respectivement, pour des raisons de compatibilité. Note : Le code suivant retourne un résultat différent. $str='abc';var_dump(isset($str['x'])); // false en PHP 5.4 ou supérieure, mais true en 5.3 ou inférieure
Convertir un tableau en chaine génère maintenant une erreur E_NOTICE, mais le résultat du transtypage reste le même : la chaine "Array".
Transformer NULL, FALSE, ou une chaine vide en objet en lui ajoutant un attribut génère maintenant une erreur E_WARNING, au lieu de E_STRICT.
Des noms de paramètres qui masqueraient une super globale entrainent désormais une erreur fatale. Ceci interdit du code comme celui-ci : function foo($_GET, $_POST) {}.
Les algorithmes de hash Salsa10 et Salsa20 ont été retirés.
L'algorithme de hash Tiger utilise maintenant l'ordre des octets big-endian. Suivre cet exemple pour écrire un code compatible avec PHP 5.3 et PHP 5.4.
array_combine() retourne maintenant array() au lieu de FALSE lorsque vous lui passez deux tableaux vides comme paramètres.
Si vous utilisez htmlentities() avec un jeu de caractères asiatique, elle fonctionnera comme htmlspecialchars() - ça a toujours été le cas avec les versions précédentes de PHP, mais maintenant, une erreur E_STRICT sera levée.
Le troisième paramètre de la fonction ob_start() a changé de type passant d'un booléen nommé erase à un entier nommé flags. Notez que la code qui définit explicitement le paramètre erase à FALSE ne fonctionnera plus comme attendu en PHP 5.4 : veuillez suivre cet exemple afin d'écrire du code compatible avec PHP 5.3 et 5.4.

Les mots-clé suivants sont maintenant réservés, et ne peuvent plus être utilisés dans les noms de fonctions, de classes, etc.

Les fonctions suivantes ont été supprimées :

define_syslog_variables()
import_request_variables()
session_is_registered(), session_register() et session_unregister().
Les alias mysqli_bind_param(), mysqli_bind_result(), mysqli_client_encoding(), mysqli_fetch(), mysqli_param_count(), mysqli_get_metadata(), mysqli_send_long_data(), mysqli::client_encoding(), et mysqli_stmt::stmt().

add a note

User Contributed Notes 3 notes

down

ky dot patterson at adlinkr dot com ¶

9 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.

down

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' );

}

?>

down

anton at zebooka dot com ¶

10 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

add a note