Миграция php 5 php 7
Мой опыт миграции на PHP 7
Несколько дней назад я переключил свой сервер с порядка 30-ти сайтами на PHP 7. Некоторые из них были достаточно старыми и составляли широкий набор с различных фреймворков и CMS. Вот несколько советов для тех кто еще не решил переходить на PHP 7 или нет.
Начнем с того что я понимаю что есть много людей которые не считают стабильную версию действительно «стабильной» пока она чуть-чуть не повзрослела, ожидая что еще найдутся какие-то баги или несовместимости. С того что я пока видел, пробуя каждый release candidate как только он выходил, совсем безопасно переключиться на PHP 7 как только он выйдет. Я ни разу не заметил какого-то непонятного поведения или вылета которому виной не был бы я сам. Несмотря на то что это новая версия она не несет много несовместимых изменений, то есть по большому счету можете относиться к ней как к просто PHP 5.7 только существенно быстрее.
И скорость действительно впечатляет, даже невероятно как. Для примера простой сайт на PHPixie заработал почти в три раза быстрее практически сравнившись со скоростью Phalcon на PHP 5.6, несколько сайтов на WordPress показали стабильный прирост в скорости в два раза. Если учесть недавний отчет от Google что потеря даже 10% производительности загрузки страниц приводит к ощутимой потери клиентов, то если вы можете запросто ускорить работу сайта в два раза просто обновив PHP вы получаете больше продаж ничего не потратив. Вспомните об этом, когда будете убеждать своего менеджера перейти на PHP 7. Ничего не убеждает лучше, чем объем продаж.
Расширение mysql больше недоступно, так что если вы еще не перешли на PDO или mysqli то теперь уж точно придется. Благо во многих случаях достаточно просто заменить вызовы к mysql_ функциям на mysqli_.
E_STRICT ошибки реклассифицированы как другие типы ошибок. Если раньше вы их прятали или игнорировали, то теперь они начнут всплывать вместе с другими. Например, вызов нестатических методов статически теперь выбрасывает E_DEPRECATED что создало кучу проблем с Joomla 2.5 который почему-то делает это довольно часто. Также несовместимое наследование теперь классифицируется как E_WARNING. WordPress уже с февраля тестируется на работу с PHP 7, так что с ним самим проблем никаких нет, правда, несколько плагинов таки оказались несовместимыми.
foreach теперь всегда работает с копией массива, так что все изменения массива во время итерации не повлияют на саму итерацию. На самом деле, во многих случаях оно и так работало и сам случай довольно редкий, но все же в одном из плагинов я на это наткнулся.
Теперь $foo->$bar[‘baz’] интерпретируется как ($foo->$bar)[‘baz’] а не $foo-> как в PHP 5. Это редкий случай, но тоже попалось в одном из плагинов, и как оказалось в Magento 1.x (core/Mage/Core/Model/Layout.php).
Имейте в виду, что не все расширения уже поддерживают PHP 7. Я уже не могу использовать понравившийся мне XCache, который верно служил мне много лет.
Вряд ли вы встретите какие-то проблемы кроме вышеперечисленных, но если вам интересно то полный список доступен на сайте PHP.
В сумме мне заняло около 5 часов чтобы перевести все сайты на PHP 7. Процесс совсем нетрудный и пакеты доступны уже для всех популярных дистрибутивов. Так что даже если вы собираетесь ждать стабильного релиза (уже совсем недолго), нет никакой причины не приготовить свои сайты к миграции наперед.
Миграция php 5 php 7
БлогNot. Миграция с PHP5 на PHP7 и PHP8: что чаще всего приходится править в исходниках
Миграция с PHP5 на PHP7 и PHP8: что чаще всего приходится править в исходниках
Для проверки фрагментов кода предполагалось, что в его начале указана директива
Уведомление Trying to access array offset on value of type null/bool/int
Часто возникает при использовании синтаксиса обращения к элементу массива на других типах данных. Пример:
Так бывает, например, если функция может возвращать массив в нормальном случае и false/null в случае ошибки, а дальше вверх по стеку информация о false/null теряется и этот случай не обрабатывается отдельно.
Применение функции mysql_real_escape_string
. которой традиционно «обезопасивали» хранимые в базе данных строки от SQL-инъекций.
Перебор массива с помощью list и each
было: while (list(,$var) = each($params)) <
или же: while (list($num,$var) = each($params)) <
— если массив перебирается как ассоциативный и/или нужны ключи его элементов.
Модификатор /e функции preg_replace
было:
$text = preg_replace(‘
надо:
$ text = preg_replace_callback(‘
— то есть, через callback-функцию.
Проблема с подключаемыми графическими шрифтами GD
было:
$bbox=imagettfbbox ($f,0,’arial.ttf’,’String’);
— если фонт лежит в папке скрипта, как обычно и бывает.
error_reporting(0) и подобное
Многие разработчики привыкли решать проблему с предупреждениями и даже сообщениями об ошибках просто выключая сообщения о них. При миграции скриптов это приводит к «загадочным белым экранам» вместо содержимого. Лучше всего вообще не трогать включённое в новых версиях протоколирование ошибок по умолчанию, а все вызовы функции error_reporting приводить к виду, указанному в начале статьи.
Строковые функции
Начиная с версии PHP 5.6 кодировкой по умолчанию стала кодировка Юникода UTF-8, соответственно, вместо прежних «си-подобных» строковых функций теперь лучше использовать их многобайтовые аналоги.
. и т.д., принцип, думаю, понятен. Будьте внимательны, проверяя, есть ли для функции многобайтовый аналог.
и нужно делать так:
С другой стороны, как видно из примера, для strtoupper и strtolower эти аналоги есть.
Применение array_key_exists к объекту, а не к массиву
Теперь нельзя применять array_key_exists к объектам классов (а можно только к массивам). Неправильно:
Итак, 8-я версия, вышедшая в ноябре-2020, теперь есть и в составе XAMPP, ниже, вероятнее всего, будут добавляться исправления для PHP8, хотя и для версии 7 всё написанное выше остаётся в силе.
Отмечу, что в сборке PHP 8.0.0 с сайта XAMPP в файле php.ini ( диск:\xampp\php\php.ini ) была по умолчанию отключена библиотека gd:
Соответственно, все функции imagecreatetruecolor, imagecreatefromgif, imagecreatefromjpeg, imagecreatefrompng и т.д. «вдруг перестали работать».
Функция get_magic_quotes_gpc удалена (PHP8)
Любые упоминания о функции get_magic_quotes_gpc теперь придётся исключить из кода, она просто удалена. При этом нужно учесть, что начиная с версии 5.4 она всё равно всегда возвращала 0.
Функция each удалена (PHP8)
Удалена в PHP8 и функция each. В общем случае можно попытаться заменить на next или array_shift, но однозначного рецепта нет из-за возможности использования функции не только в цикле, как показано выше, но и, например, в рекурсивных построениях.
Бортовой журнал
Полет нормальный. Без происшествий.
Переход на PHP7: работа над ошибками
Итак, у вас есть старенький, но уж очень милый сердцу сайт, который вы решаетесь из жалости (или, возможно, перечитав Хабра) перевести на PHP7. С волнением ожидая резкого роста производительности, вы смахиваете пыль с бедного сайта и решительно переключаете в панели управления хостингом версию PHP.
Если сайт уже давно не молод, то с большой долей вероятности чудо не произойдет. В лучшем случае начнут появляться разного рода ошибки, а в худшем — вы увидите белый экран, дзен веб-разработки. В этот момент хочется по-быстрому переключить все обратно и забыть о своей внезапной слабости.
Но предположим, что ваша сильная сторона — настойчивость, к тому же вы располагаете некоторым количеством времени для экспериментов. Давайте попробуем все починить.
Резервные копии
Делаем резервные копии сайта (а заодно и баз данных). Ведь кто не делает резервные копи — сам себе враг, верно? Для разного рода экспериментов имеет смысл добавить еще один сайт на хостинге и скопировать в него файлы, которые мы сейчас будем править.
Журналы ошибок
php_value display_errors 0
php_value log_errors 1
php_value error_log /home/vasya/domains/mysite.ru/logs/error.log
Работа с MySQL
Допустим, сайт использует базы данных, и вы видите ошибки вроде такой:
Fatal error: Uncaught Error: Call to undefined function mysql_connect()
Это оттого, что в современных версиях PHP (начиная с PHP 5.5.0) оригинальное расширение MySQL не поддерживается. Разработчики рекомендуют использовать MySQLi или PDO. Попробуем перейти на MySQLi, это просто:
Предположим, что сайт написан с использованием процедурного подхода, который представляет собой классический говнокод многие и сейчас считают лаконичным и эффективным решением. В таком случае, следующую устаревшую конструкцию для подключения к базе данных:
Другие популярные функции легко меняются на их аналоги с буквой ‘i’:
mysqli_fetch_array()
mysqli_fetch_row()
mysqli_fetch_assoc()
mysqli_fetch_array()
mysqli_num_rows()
mysqli_insert_id()
mysqli_close()
В результате этих несложных действий данные из БД должны успешно собираться и отправляться.
Кодировка
Настоящий олдскул — это сайт в CP1251 (как минимум). Всё превратилось в ромбики или прочие козяблики?
php_value default_charset «cp1251»
Регулярные выражения
Также вы можете наблюдать ошибки следующего рода:
Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
Это означает, что модификатор /e, который позволял передать произвольной функции результат регулярного выражения, теперь не поддерживается. В таких случаях рекомендуется использовать функцию preg_replace_callback
Допустим, у нас есть такое регулярное выражение:
с заменой на preg_replace_callback оно должно выглядеть вот так:
Вот еще один пример, посложнее:
здесь легко запутаться в кавычках, будьте внимательны.
Копаясь в регулярных выражениях, можно вспомнить еще про две функции, которые с версии PHP 5.3.0 считаются устаревшими (и не поддерживаются). Симптомы следующие:
Fatal error: Uncaught Error: Call to undefined function ereg_replace()
Если регулярное выражение в ereg_replace простое, то можно обойтись просто установкой граничных символов, как здесь:
Fatal error: Uncaught Error: Call to undefined function split()
Если регулярное выражение посложнее, то пробуем преобразовать к preg_split.
На этом пока все. Удачной отладки.
Много полезных материалов по теме можно найти на сайте разработчиков.
Если что-то не получается, или ваш случай совсем не похож на наши примеры — пишите комментарии, попробуем разобраться вместе.
Для того, чтобы оставлять комментарии к посту, авторизуйтесь, используя свой аккаунт в социальных сетях ВКонтакте/FaceBook, или аккаунт в Google/Яндекс.
Переходите с PHP 5.6 на PHP 7 и бесплатно ускорьте работу своего сайта
Рекомендация для пользователей Webasyst в 2020 году.
А вы знали, что Webasyst начнёт работать быстрее, если просто сменить версию PHP?
Если вы ещё используете PHP версии 5.6 или ниже, переключитесь на PHP 7. После этого снизится нагрузка на сервер и страницы сайта начнут открываться быстрее.
Насколько быстрее станет работать сайт после смены версии PHP?
Примерно на 25%–35%, а в некоторых случаях и до 49% — мы проверили.
Почему сайт станет работать быстрее?
Это произойдёт благодаря использованию более современной версии интерпретатора PHP, который установлен на хостинге. Начиная с версии 7.0 интерпретатор стал заметно быстрее исполнять почти любой программный код, написанный на языке программирования PHP.
Мы сравнили скорость работы Webasyst с разными версиями PHP
Настроили интернет-магазин на виртуальном хостинге, установили плагин «Яндекс.Маркет» и добавили в магазин несколько сотен товаров. Настроили фильтры в категориях товаров и автоматическое обновление YML-файла в профиле экспорта плагина «Яндекс.Маркет».
Потом измерили скорость открытия некоторых адресов сайта при использовании разных версий PHP.
Результаты проверки для PHP 5.6 и 7.2
Разделы сайта | PHP 5.6 | PHP 7.2 | Ускорение работы |
---|---|---|---|
Главная страница | 0,176 сек | 0,114 сек | 35% |
Страница товара | 0,199 сек | 0,108 сек | 46% |
Категория товаров с фильтрацией | 0,310 сек | 0,229 сек | 26% |
YML-файл | 5,969 сек | 3,055 сек | 49% |
В среднем | 39% |
В этой таблице мы собрали средние значения для двух популярных сегодня версий PHP: 5.6 и 7.2. Видно, что ускорение работы сайта возможно в среднем на треть. Даже если ваш сайт станет работать «всего лишь» на 25% или на 20% быстрее, то это всё равно очень неплохой результат, который вам ничего не будет стоить.
Если принять текущую скорость работы сайта с PHP 5.6 за 100% (коричневые столбцы на графике), то зелёные столбцы покажут в сравнении, насколько меньше времени требуется серверу для обработки запросов после перехода на PHP 7.
Как перейти на PHP 7
Возможность переключиться на другую версию PHP часто доступна в контрольной панели хостинга. Если вы не можете найти эту настройку, попросите службу поддержки хостинга сменить версию PHP для вашего сайта.
Возможны ли проблемы при переходе на PHP 7?
Теоретически это возможно, только если у вас установлены приложения, плагины или виджеты, в исходном коде которых используются возможности устаревших версий PHP, которые более не доступны в PHP 7. Если необходимо, поищите их аналоги, написанные с поддержкой более современных версий PHP, в магазине Webasyst.
Что будет, если остаться на PHP 5.6?
Эта версия больше не поддерживается начиная с 1 января 2019 года. Это значит, что в ней больше не будут устраняться критические ошибки и уязвимости. Лучше работать с поддерживаемой современной версией, для которой выпускаются обновления.
Сейчас доступно несколько разных версий PHP 7 — можно переходить на любую?
Можно переходить на любую из версий PHP 7, чтобы ускорить работу сайта: 7.0, 7.1, 7.2, 7.3, 7.4. Разумно выбрать ту версию, которая в данный момент активно поддерживается. Ориентируйтесь на общедоступные сроки поддержки версий PHP.
Например, на 19 февраля 2020 года активно поддерживаемые версии (зелёный фон) — 7.3 и 7.4, а для версии 7.2 только изредка выпускаются исправления критических ошибок (оранжевый фон).
Если на вашем хостинге недоступен PHP нужной версии, перенесите свой сайт на другой хостинг, где такая версия есть.
Миграция php 5 php 7
Добрый день уважаемые читатели и подписчики, наверняка многие из вас слышали информацию, о том, что поисковая система Google прилагает огромные усилия, для перевода всех сайтов в интернете на безопасное соединение https, за счет установки сертификатов шифрования для веб сайтов, предлагая вебмастерам получить бонусы в поисковой выдаче, при прочих равных. Вот и я всерьез задумался над этой задачей, планируя осуществить переезд сайта в летнее время, но перед этим делом я должен все подготовить и одной из ступеней подготовки я для себя поставил, переход с php 5 на php 7, на своем хостинге mchost.ru
Для чего мне переход с php 5 на php 7
На это меня натолкнуло две вещи:
Я вам уже описывал в статье, как мой сайт загибался от нагрузки парсинга не него, и техническая поддержка, после решения проблем, так же порекомендовала, при поддержке сайтом php 7, перейти именно на нее. Тесты сравнения производительности php 5 и php 7, смотрите по ссылке.
Смена версии php
Так как у меня VPS хостинг на mchost, то это делается очень просто. Заходим в личный кабинет, по адресу https://cp.mchost.ru/login.php. Далее как любой нормальный человек, вы должны сделать резервную копию сайта. Заходим в пункт резервные копии, выбираем сайт и создаем.
Следующим шагом, вы выбираете пункт сайты. Находите среди них нужный и нажимаете Настройки php.
В пункте php для домена, у вас отобразится список возможных версий, на текущий момент самой последней является FastCGI PHP 7.1
Начнется процесс перехода с php 5 на php 7, в справа у вас будет прогресс бар.
как видите, до изменения версии, у меня это 5.4.45
Если кстати хотите получить 3 месяца халявы от данного хостинга, то щелкайте по баннеру ниже и вводите промокод 48C4-D018-AC60-50C6
После того как вы перевели сайт на свежую версию, проверьте весь функционал вашего ресурса, все ли работает и отображается корректно, если нет у вас два выхода, 1 это откатиться, второй это доработать сайт.
Возможные проблемы
Бывают случаи, что вы получаете ошибку: Ошибка установки соединения с базой данных
Решается она просто, вам нужно обновить пароль на базу данных, в личном кабинете. Выбираем пункт Базы данных и щелкаем по нужной (редактировать)
Задаем заново пароль.
Если например вы не помните пароль от нее и у вас движок сайта, как и у меня WordPress, то можно подключить к ftp серверу и найти в корне сайта файл wp-config.php
Откройте его и найдите поле (Пароль к базе данных MySQL)