Комментарии 35
Как ни странно, у меня совместимость поломалась не между 5.6 и 7.1, как можно было бы ожидать, а между 7.1 и 7.2 из-за появления ключевого слова Object.
В Yii2 это уже пофиксили, да никак не доходят руки накатить новую версию и перепроверить на сайте-стотысячнике.
Ну а обычно сложность только возникает, если используется mysql_ библиотека и просто из-за отсутствия штатных разработчиков, которые бы поддерживали актуальность скрипта. Многие сайты работают по принципу: «работает — не трогай».
В Yii2 это уже пофиксили, да никак не доходят руки накатить новую версию и перепроверить на сайте-стотысячнике.
Ну а обычно сложность только возникает, если используется mysql_ библиотека и просто из-за отсутствия штатных разработчиков, которые бы поддерживали актуальность скрипта. Многие сайты работают по принципу: «работает — не трогай».
сложность только возникает… просто из-за отсутствия штатных разработчиков, которые бы поддерживали актуальность скрипта. Многие сайты работают по принципу: «работает — не трогай».
Это самая большая проблема индустрии :(
К сожалению, чем дольше ждать, тем сложнее довести скрипт до новой версии
Я на upwork беру только небольшие проекты, и в 25% случаев это переезд с mysql_xxx на PDO :) Так как хостинг провайдеры переводят сайты на новые версии и они перестают работать :)
Имхо, есть смысл сделать возможность выбирать несколько пунктов в опросе. А то сложно выбирать, когда имеется несколько проектов на разных версиях
Если у пользователя старый php. Значит и Plesk тоже старый. И не собирает информацию о php. Разве нет?
У пользователей свежего Plesk-а, как оказалось, старого PHP тоже очень много, тем более, что мы пока его поддерживаем. Нам эта поддержка стоит ресурсов — именно поэтому мы и заинтересовались, насколько это в действительности актуально для наших клиентов.
Версия PHP не так сильно зависит от версии Plesk, сколько от версии OS — у многих остается стоковый PHP.
Plesk вначале начал давать возможность подключить самособранные PHP, а затем (тоже давно уже) начал поставлять дополнительные версии PHP сам, чтобы решить проблему с отсутствием нужной сборки и сложность сборки самостоятельной, но раньше не было известно — кто и что выбрал.
Plesk вначале начал давать возможность подключить самособранные PHP, а затем (тоже давно уже) начал поставлять дополнительные версии PHP сам, чтобы решить проблему с отсутствием нужной сборки и сложность сборки самостоятельной, но раньше не было известно — кто и что выбрал.
А вы не пробовали искать корреляции с наплывами пользователей?
К примеру, количество клиентов из России и Японии падает, поэтому большая часть проектов — легаси, в котором страшно что-то менять, а из Литвы и Кореи растёт, поэтому там больше свежих проектов с новыми версиями PHP?
К примеру, количество клиентов из России и Японии падает, поэтому большая часть проектов — легаси, в котором страшно что-то менять, а из Литвы и Кореи растёт, поэтому там больше свежих проектов с новыми версиями PHP?
Обновился на PHP 7.2 — люблю всё новое.)
возможно еще причина в том, что панели больше предпочитают владельцы не особо продвинутые в администрировании, соответственно не стремящиеся что-то лишний раз менять, обновлять и перенастраивать, пока и так работает
Какие ужасные диаграммы — сразу 3 синих цвета. Я так ничего не понял, без графического редактора я так и не понял где PHP 5.5 а где 7.2
«Предпочитаете» неудачное слово, по-моему. Скорее или вообще таких нюансов не знают, или вынуждены.
Китай — версия 4.4
WTF…
И вот сидишь такой, развернул локалку, поставил 7.2 да ещё заморских приблуд и прогаешь на ней, а потом приходишь в компанию, а там 5.3. И никому там неинтересно, что появились типы аргументов, есть PDO, сокращённые конструкции if() и ещё много чего. Бизнес любит стабильность. Печально все это (
В документации написано, что PDO еще в 5.1 были встроены.
Как бы то не было. Лишь после выхода 5.6 стал замечать (в очень редких случаях) PDO в коде. Хотя, мб мне не самые лучше проекты попадались…
Очень удивлен высоким долям версий ниже 5.6. Я могу понять инертность в переходе на 7.x, у самого есть 1 проект, изобилующий mysql_. Начинался он с ранних версий 5.3, но на каждую новую версию вплоть до 5.6, включительно, обновлялся регулярно.
Ну уж и не знаю, почему все так трясутся за старые РНР версии. Помню 3 года назад была поставлена задача произвести оценку возможности отказа от PHP 4.0, 4.4, 5.2 (было это в ноябре 2015 года тогда же мы решили отказатья и от MySQL 4.x, но речь пойдёт именно о РНР). Сразу хочу пояснить, что речь идет о практически единственном немецком хостинг-провайдере который так долго поддерживал старые версии пхп. Первичный анализ показал, что после того как основные хостеры в начале 2015 году потключали 4.4, мы получили огромное количество новых клиентов с Joomla 1.5, 1.0 и даже Mambo и отключение версий до 5.2 затронет оргомное количество клиентов. Но тут настал декабрь 2015 года со своей замечательной уязвимостью всех Joomla через UserAgent SQL-Injection. Хотя после 2-3 часов после первых взломанных сайтов мы очень быстро отреагировали и нарисовали пару правил для mod_security остановив взломы, но хакеры успели сделать своё дело: большинство клиентских сайтов на основе joomla была взломана. Это был просто кошмар техподдержка захлёбывалась, техники работали на износ. Восстановление из старых бэкапов не приносило облегчения, потому что появлялись всё новые известые дыры, которые уже невозможно было закрыть десятками mod_security и apparmory правил: сервера просто не справлялись. Росла нагрузка и со стороны iptables: Приходилось блокировать десятки тысяч адресов активных ботнетов. В конце концов было принято волевое решение блокировать взломанные Joomla 1.5 совсем и требовать от клиентов полностью сносить сайт и установливать новую версию Joomla либо WP
Была проведена огромная разъяснительная работа с клиетами по электронной почте, телефону. Было выделено несколько коллег, которые помогали переносить данные со старых сайтов на новые Joomla либо Wordpress. В результате огромной работы уже в августе 2016 года мы смогли отказатся от поддержки PHP 5.2, 5.3 и даже 5.4
Самое забавное, что некоторые пользователи Wordpress заметили что сайты стали работать гораздо быстрее и писали нам в техподдержку «Вы что-то исправили у меня на сайте? Он теперь быстрее открывается. Мне нужно больше платить ?»
Суть этой истории проста: не нужно боятся отказываться от старых, неподдерживаемых версий.
Была проведена огромная разъяснительная работа с клиетами по электронной почте, телефону. Было выделено несколько коллег, которые помогали переносить данные со старых сайтов на новые Joomla либо Wordpress. В результате огромной работы уже в августе 2016 года мы смогли отказатся от поддержки PHP 5.2, 5.3 и даже 5.4
Самое забавное, что некоторые пользователи Wordpress заметили что сайты стали работать гораздо быстрее и писали нам в техподдержку «Вы что-то исправили у меня на сайте? Он теперь быстрее открывается. Мне нужно больше платить ?»
Суть этой истории проста: не нужно боятся отказываться от старых, неподдерживаемых версий.
Одна из существенных причин отказа была как раз экономическая: трудоёмкость поддержки старых версий на 12 убунте. Если вы помните, десятая убунта с древними РНР и MySQL закончилась как раз весной 2015 года. Да и конец 12 убунты был уже рядом. К тому же, в это время мы отказывались от 32 битных ОС (и серверов с 32 битными процессорами). У PHP 5.2 часто текла память, были очень странные и неприятные взломы. Расследование отнимало много времени у техников и безопасников и в конце концов мы находили дыры (переполнение памяти, кривые проверки и прочая дичь), что можно патчили, совсем экзотическое закрывали другими способами. С 5.3 было еще сложнее, потому что в отличии от 5.2 в случае утечек памяти или взлома накрывался FPM пул для всех клиетнов этого сервера. итд итп
Потери клиентов были не такие уж и значительные т.к. во первых: уже не было к кому бежать, во вторых мы помогли большинству клиентов обновится до чего-то более свежего.
Потери клиентов были не такие уж и значительные т.к. во первых: уже не было к кому бежать, во вторых мы помогли большинству клиентов обновится до чего-то более свежего.
Заранее была задумана стратегия "не будем прекращать поддержку до последнего, чтобы от тех, кто прекратил раньше, бежали к нам, а когда останемся последними прекратим, ведь некуда будет бежать" или просто осознали почему конкуренты прекратили раньше? Если заранее, то большой респект :)
В Германии очень ценится стабильность. Любые изменения принимаются очень болезненно, даже если речь идёт о переходе на более дешёвый тариф с большими возможностями. Стабильностью были привлечены клиенты.
Во вторых в Германии очень ценится качественная техподдержка (яркие примеры: клиенты О2 могут висеть по 30-50 минут на телефоне дожидаясь ответа оператора. Другой пример — платные номера техподдержки: от 10 центов до евро в минуту) — Вторым нашим шагом была огромная работа техподдержки по удержанию клиентов.
Все остались в выигрыше: и мы с низкими затратами на поддержку софта и клиенты с более или менее новыми/залатаными сайтами
Во вторых в Германии очень ценится качественная техподдержка (яркие примеры: клиенты О2 могут висеть по 30-50 минут на телефоне дожидаясь ответа оператора. Другой пример — платные номера техподдержки: от 10 центов до евро в минуту) — Вторым нашим шагом была огромная работа техподдержки по удержанию клиентов.
Все остались в выигрыше: и мы с низкими затратами на поддержку софта и клиенты с более или менее новыми/залатаными сайтами
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PHP 5.x – старикам здесь (не) место