Хотя большая часть существующего кода PHP 5 должна работать без изменений, всё же ознакомьтесь с некоторыми изменениями, которые могут сказаться на обратной совместимости:
Раньше объявленные как свойства класса массивы, в которых смешались явные и неявные ключи, могли без предупреждения перезаписывать элементы массива, если явный ключ пересекался с последовательным неявным ключом. Например:
<?php
class C
{
const ONE = 1;
public $array = [
self::ONE => 'foo',
'bar',
'quux',
];
}
var_dump((new C())->array);
?>
Результат выполнения приведённого примера в PHP 5.5:
array(2) { [0]=> string(3) "bar" [1]=> string(4) "quux" }
Результат выполнения приведённого примера в PHP 5.6:
array(3) { [1]=> string(3) "foo" [2]=> string(3) "bar" [3]=> string(4) "quux" }
Теперь функция json_decode() в соответствии со
спецификацией JSON отклоняет JSON-литералы
true
, false
и
null
, которые задали не строго в нижнем регистре,
и, соответственно, устанавливает
код ошибки для функции json_last_error(). Раньше данные,
которые передавались в функцию json_decode()
и содержали исключительно одно из этих значений в верхнем
или смешанном регистре, принимались.
Это изменение повлияет только в случае передачи в функцию json_decode() некорректного JSON. В случае корректно сформированного JSON никакого эффекта не будет.
Все шифруемые клиентские потоки теперь по умолчанию включают проверку пиров. По умолчанию сертификат пира проверяется пакетом OpenSSL CA. Обычно не нужно ничего делать для соединения с серверами с правильным SSL-сертификатом, так как OpenSSL настроен так, что уже работает с хорошими CA-пакетами.
Стандартный CA пакет может быть переопределён глобально с помощью
установки или openssl.cafile или openssl.capath строк конфигурации,
или же на уровне каждого запроса используя опции контекста
cafile
или
capath
.
Хотя это и не рекомендуется, но можно отключить проверку сертификата пира
для запроса, установив verify_peer
опцию контекста в false
, и можно отключить проверку имени пира, установив
verify_peer_name
в false
.
Теперь ресурсы GMP — объекты. Функциональный API, который реализовали в модуле GMP, остался без изменений. Существующий код должен заработать без изменений, только если в нём явно не использовались проверки на ресурс is_resource() или что-то подобное.
mcrypt_encrypt(), mcrypt_decrypt(), mcrypt_cbc(), mcrypt_cfb(), mcrypt_ecb(), mcrypt_generic() и mcrypt_ofb() больше не принимают ключи и IV с некорректной длиной, а режимы блочного шифра, требующие IV, будут завершаться с ошибкой, если его не передать.