Бортовой журнал. Бортовой журнал Переход на php 7
Стоит ли переходить на новую версию PHP 7.0 ? – Однозначно стоит, даже не думайте - переходите!
В седьмой версии достаточно много нововведений. Основные из них:
- в основе ядра PHP 7 используется PHPNG . Новое ядро дает прирост производительности сайтам от 40%;
- type Hints и возвращаемые значения . Теперь при объявлении функции для каждой переменной можно указывать свой тип, а также тип данных, который вернет функция. Доступные типы: int , float , string и bool ;
- комбинированный оператор сравнения и многое другое.
В PHP 7 были удалены некоторые расширения:
- mysql
Уже в PHP 5.6.x использование этих расширений было нежелательным. Вместо «mysql» следует использовать «PDO», а вместо ereg → preg .
Более детально ознакомиться с новинками PHP 7 можно на официальной странице
Стоит ли переходить на PHP 7?
На данный момент самое простое, что вы можете сделать для увеличения производительности сайта, это перейти на PHP 7.0.x. Прирост скорости также зависит от того, как написан ваш проект. Если вы еще сомневаетесь, покажем некоторые сравнения:
Бенчмарки PHP 5.6 vs PHP 7 для нектоторых фреймфорков (Zend framework, Magento, Drupal, Mediawiki, WordPress, Laravel, SugarCRM и др):
По всем фреймворкам прирост производительности значительный. Давайте посмотрим, как обстоит дело с функциями и конструкциями ядра:
Бенчмарки PHP 5.6 vs PHP 7 для функций и конструкций ядра:
Если графики вас убедили, можно попробовать перенести свой сайт на новую версию PHP и ощутить прирост на реальном проекте.
Коллеги с Elasticweb рассказали, что перед запуском нового сервера с PHP 7 они запустили на нем крупный государственный проект, работающий на Laravel 5. Это был своеобразный тест производительности новой версии PHP и сервера в целом. Ранее этот проект был на сервере с PHP 5.6. После переноса сайта страницы начали открываться значительно быстрее, при этом использование ресурсов сократилось вдвое.
Для подготовки переезда на PHP 7 они использовали PHP 7 Migration Assistant Report (MAR) . Большинство популярных CMS/Framework уже обладают совместимостью с PHP 7, поэтому основная задача сводилась к тестированию custom плагинов.
WordPress 4, Drupal 8/7 и последняя версия Joomla уже готовы к PHP 7!
Итак, у вас есть старенький, но уж очень милый сердцу сайт, который вы решаетесь из жалости (или, возможно, перечитав Хабра) перевести на PHP7. С волнением ожидая резкого роста производительности, вы смахиваете пыль с бедного сайта и решительно переключаете в панели управления хостингом версию PHP.
Если сайт уже давно не молод, то с большой долей вероятности чудо не произойдет. В лучшем случае начнут появляться разного рода ошибки, а в худшем - вы увидите белый экран, дзен веб-разработки. В этот момент хочется по-быстрому переключить все обратно и забыть о своей внезапной слабости.
Но предположим, что ваша сильная сторона - настойчивость, к тому же вы располагаете некоторым количеством времени для экспериментов. Давайте попробуем все починить.
Резервные копии
Делаем резервные копии сайта (а заодно и баз данных). Ведь кто не делает резервные копи - сам себе враг, верно? Для разного рода экспериментов имеет смысл добавить еще один сайт на хостинге и скопировать в него файлы, которые мы сейчас будем править.
Журналы ошибок
Настроим ведение журнала ошибок PHP в файл.htaccess (если он не был настроен ранее):
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, это просто:
Предположим, что сайт написан с использованием процедурного подхода, который представляет собой классический говнокод многие и сейчас считают лаконичным и эффективным решением. В таком случае, следующую устаревшую конструкцию для подключения к базе данных:
$link = mysql_connect(‘localhost’, $user, $password)
mysql_select_db($dbname, $link)
mysql_query(‘set names cp1251’)
можно заменить на:
$link = mysqli_connect(‘localhost’, $user, $password, $dbname)
mysqli_query($link, ‘set names cp1251’)
для запросов:
$result=mysql_query($query,$cid)
заменить на:
$result=mysqli_query($cid, $query)
Другие популярные функции легко меняются на их аналоги с буквой ‘i’:
mysqli_fetch_array()
mysqli_fetch_row()
mysqli_fetch_assoc()
mysqli_fetch_array()
mysqli_num_rows()
mysqli_insert_id()
mysqli_close()
В результате этих несложных действий данные из БД должны успешно собираться и отправляться.
Кодировка
Настоящий олдскул - это сайт в CP1251 (как минимум). Всё превратилось в ромбики или прочие козяблики?
Скорее всего, достаточно будет указать кодировку в.htaccess таким образом:
php_value default_charset «cp1251»
Регулярные выражения
Также вы можете наблюдать ошибки следующего рода:
Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
Это означает, что модификатор /e, который позволял передать произвольной функции результат регулярного выражения, теперь не поддерживается. В таких случаях рекомендуется использовать функцию preg_replace_callback
Допустим, у нас есть такое регулярное выражение:
$string=preg_replace(«/:({1,10}):/e», «print_smile(‘\\1’)», $string)
с заменой на preg_replace_callback оно должно выглядеть вот так:
$string=preg_replace_callback(«/:({1,10}):/», create_function(‘$matches’, ‘return print_smile($matches)’), $string)
здесь все просто, регулярное выражение теперь указывается в качестве первого аргумента (без модификатора /e, разумеется), а в качестве второго аргумента указывается анонимная функция (которая будет выполнена после применения регулярного выражения) с двумя аргументами: массив $matches, где будут сохранены данные, совпадающие с регулярным выражением и вызов внешней функции с аргументами. В данном примере внешняя функция называется print_smile и ей передается аргументом первое найденное вхождение. То, что в preg_replace было \\1 (первое найденное вхождение) станет $matches (если аргументов было больше, то будет $matches, $matches и так далее).
Вот еще один пример, посложнее:
Было так:
$out=preg_replace(«/<(=[\’\»]{0,1}|)(.*?)([\’\»]{0,1})>(.*?)<\/>/es», «feed_out_sub_rm(‘\\2′,’$base_prefix’,’$nick’,’$id_entry’)», $out)
Стало вот так:
$out=preg_replace_callback(‘/<(=[\’\»]{0,1}|)(.*?)([\’\»]{0,1})>(.*?)<\/>/s’, create_function(‘$matches’, ‘return feed_out_sub_rm($matches, «‘.$base_prefix."», «‘.$nick."», «‘.$id_entry."») ‘), $out)
здесь легко запутаться в кавычках, будьте внимательны.
Копаясь в регулярных выражениях, можно вспомнить еще про две функции, которые с версии PHP 5.3.0 считаются устаревшими (и не поддерживаются). Симптомы следующие:
Fatal error: Uncaught Error: Call to undefined function ereg_replace()
Если регулярное выражение в ereg_replace простое, то можно обойтись просто установкой граничных символов, как здесь:
$str=ereg_replace(«[\r\t\n]»,»»,$str)
$str=preg_replace(«/[\r\t\n]/»,»»,$str)
Аналогичный симптом:
Fatal error: Uncaught Error: Call to undefined function split()
$var_pair=split(«=»,$tmp)
$var_pair=explode(«=»,$tmp)
Если регулярное выражение посложнее, то пробуем преобразовать к preg_split.
Если что-то не получается, или ваш случай совсем не похож на наши примеры - пишите комментарии, попробуем разобраться вместе.
Для того, чтобы оставлять комментарии к посту, авторизуйтесь, используя свой аккаунт в социальных сетях ВКонтакте/FaceBook, или аккаунт в Google/Яндекс.
Решил написать о переходе на PHP 7
, так как сам сейчас занять переводом кода одного движка по PHP 7. И так для начала включаем дебаг или отладчик в админ панели сайта, если такого нет у вас, то можно сделать так, как написано в теме: , теперь на экране монитора, мы можем видеть сообщения ошибках, например, такое:
Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead - dir/file.php (номер строки)
Это сообщение говорит о том, что модификатор e не существует в PHP 7, следует избавляться от него, но если просто удалить данный модификатор, сценарий может выполнятся неправильно, непросто же так его туда писали. Я покажу на примере кода из PHPFOX 3 (как я переписывал код: ), делаем так:
Например, у нас сообщение ошибки указывает на такую строчку:
$sStr = preg_replace("/\.+?\[\/x\]/ise", """.stripslashes(\$this->_parseUserTagged("$1")).""", $sStr);
Её следует изменить так:
$sStr = preg_replace_callback("/\.+?\[\/x\]/is", function($match) { return stripslashes($this->_parseUserTagged($match)); }, $sStr);
Тут мы заменили функцию preg_replace() , на preg_replace_callback() , удалили модификатор e в первом аргументе, которым является регулярное выражение. Второй аргумент заменили анонимной функцией, которая будет выполнятся после применения регулярного выражения. Анонимная функция содержит массив $match , элементы массива заменяют совпадения, например, было: $1 , стало: $match ; было: $2 , стало: $match , и так далее. Убрали кавычки и символ экранирования (обратный слеш \).
В завершении об ошибки несуществующего модификатора e , покажу ещё пару примеров замены кода. Строку:
$aRow["value_actual"] = preg_replace("/s:(.*):\"(.*?)\";/ies", ""s:".strlen("$2").":\"$2\";"", $aRow["value_actual"]);
Меняем так:
$aRow["value_actual"] = preg_replace_callback("/s:(.*):\"(.*?)\";/is", function($match) { return "s:" . strlen($match) . ":"" . $match . "";"; }, $aRow["value_actual"]);
И пример с переменной в регулярном выражении, строка:
$sTxt = preg_replace("/\[" . $sBbcode . "=(.*?)\]/ise", """.\$this->_replaceBbCode("" . \$sBbcode . "", "prefix", true, "$1").""", $sTxt);
Заменяется так:
$sTxt = preg_replace_callback("/\[" . $sBbcode . "=(.*?)\]/is", function($match) use($sBbcode) { return $this->_replaceBbCode($sBbcode, "prefix", true, $match); }, $sTxt);
Тут мы добавили функцию use() , в которую поместили переменную из регулярного выражения, тем самым передали переменную в анонимную функцию. Если переменных в регулярном выражении будет больше одной, то просто перечисляем их через запятую, пример:
function($match) use($a, $b, $c)
Устаревшая функция ereg_replace()
Как сообщил официальный сайт PHP: http://php.net/:
С версии PHP 5.3.0 эта функция считается УСТАРЕВШЕЙ. Крайне не рекомендуется полагаться на эту возможность.
А уж в PHP 7 про неё вообще забыли... Можно получить такое сообщение об ошибки:
Fatal error: Uncaught Error: Call to undefined function ereg_replace()
Эту функцию следует заменить на preg_replace() , следуя примеру ниже. Допустим у нас такая строка кода:
$str = ereg_replace("[^ -<>-}]", " ", str_replace("\x00", " ", $originalcommentname));
Изменяем код так: 1 января 2016
Выпуск PHP 7.0.0 состоялся ещё в декабре 2015 года, но вопрос перехода на эту версию до сих пор волнует умы прогрессивной молодёжи. И не мудрено, ведь каждый значительный выпуск PHP несёт в себе множество полезных нововведений.
Зачем обновляться?
Производительность
В сети можно встретить множество синтетических и реальных тестов производительности разных версий PHP и HHVM, которые говорят только об одном - с каждой версией PHP веб становится быстрее и быстрее. Большинство же моих проектов работают на MODX Revolution и CodeIgniter 3. И, естественно, мне было любопытно узнать, что изменится после смены версии PHP.
MODX Evolution
Конечно, я бы мог проверить изменение производительности и для MODX Evolution, но в этой системе очень много кода, зависящего от, как я написал выше, удалённых расширений PHP. Однако, в версии , подготовленной пользователем , появилась полная поддержка PHP 7.
MODX Revolution
Итак, я взял несколько сайтов, работающих на PHP 5.6. Измеряю я обычно количество запросов и время на генерацию страницы. Логично предположить, что количество запросов мало коррелирует с версией PHP, но лишним добавить и эту информацию не будет. Начиная с версии реализована полная совместимость с PHP 7. До этого была лишь частичная поддержка PHP 7, ввиду чего у меня не работала админка, хотя сам сайт отлично работал.
Сайт №1
| Версия PHP | Кэширование | Запросов | Время, с |
| 5.6 | 156 | 1.18 | |
| 5.6 | 17 | 0.25 | |
| 7 | 161 | 0.43 | |
| 7 | 17 | 0.02 |
Сайт №2
Сайт №3
Как видно, переключение версии PHP на последнюю положительно сказалось на производительности сайтов, увеличив её в 1.5-3 раза, а кое-где (например, на главной странице моего сайта) даже в 10 раз.
CodeIgniter 3
Я не могу похвастаться большим количеством проектов на CodeIgniter, но даже они обязывают внимательно относиться к производительности, так как количество статей и уникальных посетителей в месяц на одном из них исчисляется тысячами. На данный момент я занимаюсь оптимизацией и рефакторингом одного из них, где и без перехода на PHP 7 производительность кое-где возросла в несколько раз. В ближайшее время, когда я закончу текущую работу, я обязательно напишу о результатах смены версии.
Синтаксис
Синтаксис претерпел некоторые изменения, которые повлияют на обратную совместимость. Помимо официальной документации советую изучить примеры кода на GitHub, например, эти: .
Кому не стоит обновляться
Не стоит обновляться тем, чьи проекты основаны на расширениях, удалённых в новом PHP. Также стоит поискать в интернете информацию о незначительных изменениях синтаксиса, так как есть моменты, нарушающие обратную совместимость. Конечно, таких случаев один на тысячу, если не реже, но лучше перестраховаться.
Хостинг-провайдеры
Выпуск PHP 7 состоялся относительно недавно, поэтому не все хостинг-провайдеры дают возможность опробовать новинку. Например, beget уже позволяет порадоваться скоростью, а в timeweb, наверное, считают PHP 7 недостаточно стабильным.
Чужой опыт
Вывод
За переход на последнюю версию PHP больше «За», чем «Против». Поэтому, если вам охота лёгкой оптимизации, обновляйте PHP.
Добрый день уважаемые читатели и подписчики, наверняка многие из вас слышали информацию, о том, что поисковая система Google прилагает огромные усилия, для перевода всех сайтов в интернете на безопасное соединение https, за счет установки сертификатов шифрования для веб сайтов , предлагая вебмастерам получить бонусы в поисковой выдаче, при прочих равных. Вот и я всерьез задумался над этой задачей, планируя осуществить переезд сайта в летнее время, но перед этим делом я должен все подготовить и одной из ступеней подготовки я для себя поставил, переход с php 5 на php 7, на своем хостинге mchost.ru
Для чего мне переход с php 5 на php 7
На это меня натолкнуло две вещи:
- Я получаю больше функциональных возможностей от php 7
- Я уменьшаю нагрузку на свои ресурсы и уменьшая количество запросов, тем самым увеличивая скорость загрузки сайта, очень сейчас актуально для мобильной поисковой выдачи, процент которой уже перевалил за 50 процентов.
Я вам уже описывал в статье, как мой сайт загибался от нагрузки парсинга не него, и техническая поддержка, после решения проблем, так же порекомендовала, при поддержке сайтом 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
Смотрим теперь 7.1
Хочу отметить, что сам перевод между версиями, может занять до 15 минут, так, что лучше это действие отложить на вечернее время
Если кстати хотите получить 3 месяца халявы от данного хостинга, то щелкайте по баннеру ниже и вводите промокод 48C4-D018-AC60-50C6
После того как вы перевели сайт на свежую версию, проверьте весь функционал вашего ресурса, все ли работает и отображается корректно, если нет у вас два выхода, 1 это откатиться, второй это доработать сайт.
Возможные проблемы
Бывают случаи, что вы получаете ошибку: Ошибка установки соединения с базой данных
Решается она просто, вам нужно обновить пароль на базу данных, в личном кабинете. Выбираем пункт Базы данных и щелкаем по нужной (редактировать)
Задаем заново пароль.
Если например вы не помните пароль от нее и у вас движок сайта, как и у меня WordPress, то можно подключить к ftp серверу и найти в корне сайта файл wp-config.php
Откройте его и найдите поле (Пароль к базе данных MySQL)
Если у вас возникают,еще какие то проблемы, то пишите о них в комментариях и мы попробуем решить их вместе. Так, что не поленитесь проделать данную задачу, важно использовать все возможности свежего программного обеспечения, тем более, вы еще бонусом получаете меньшую нагрузку на хостинг и большую скорость работы вашего ресурса.
