Статистика версий PHP — выпуск 2022.2
Напоминаю, что вся статистика открыта и все диаграммы доступны любому пользователю по ссылке https://packagist.org/php-statistics .
Статистика использования
Начнем с процентной доли версий PHP, используемых сегодня, и сравним ее с двумя предыдущими версиями:
| Версия | июль 2021 г. (%) | Январь 2022 г. (%) | июль 2022 г. (%) |
| 8.1 | 0.1 | 9.1 | 24.5 |
| 8.0 | 14.7 | 23.9 | 20.6 |
| 7.4 | 46.8 | 43.9 | 38.4 |
| 7.3 | 19.2 | 12.0 | 8.0 |
| 7.2 | 10.4 | 6.6 | 5.1 |
| 7.1 | 3.8 | 2.4 | 1.9 |

Можно заметить, что сюда не входят версии, использование которых не превышает 1%. Визуализация этих данных выглядит примерно так:
Как и ожидалось, в течение года PHP 8.1 растет, а использование PHP 8.0 уже снижается. Хороший знак — что разработчики обновляются! Имейте в виду, что PHP 8.0 будет активно поддерживаться еще четыре месяца. Так что, если вы еще не начали обновляться до PHP 8.1, сейчас самое время.
Но пока более 50% разработчиков все еще используют PHP 7.4 или ниже. Это немалое число, учитывая, что PHP 7.4 получает обновления безопасности еще 5 месяцев, а более старые версии просто больше не поддерживаются.
Переходя к обзорной диаграмме за все время, вы можете увидеть эволюцию использования версий с течением времени:

Интересно сравнить пик 5.5 в 2014 году с пиком 7.4 два года назад. PHP 5.5 и последующие версии испытали гораздо более быстрый спад, как только PHP 7.0 стал доступен, по сравнению с PHP 7.4, когда был выпущен PHP 8.0. Немного странно, что PHP 8.0 не был таким захватывающим, как PHP 7.0.
В наши дни страх перед обновлением не должен быть препятствием по сравнению с тем, что было восемь лет назад: теперь у нас есть зрелые инструменты, такие как Rector и PHP CS, которые позаботятся о почти всем пути обновления за вас.
Так почему же люди не обновляются до PHP 8.0? Почему больше людей остаются с PHP 7.4 по сравнению с 5.5 и 5.6 днями? Окончательного ответа нет.
Требуемые версии
Итак посмотрим на другую метрику — минимальная требуемая версия пакетов. Если использовать анализатор популярных пакетов Никиты Попова, чтобы загрузить 1000 самых популярных пакетов, и написать небольшой скрипт, чтобы получить самую низкую версию, которую они поддерживают, из их файлов composer.json, то получатся такие данные:
| Версия | июль 2021 г. | январь 2022 г. | июль 2022 г. |
| PHP 8.1 | — | — | 125 |
| PHP 8.0 | 117 | 160 | 94 |
| PHP 7.4 | 56 | 69 | 86 |
| PHP 7.3 | 133 | 116 | 104 |
| PHP 7.4 | 142 | 133 | 130 |
| PHP 7.1 | 182 | 190 | 153 |
| PHP 7.0 | 31 | 29 | 29 |
| PHP 5.6 | 61 | 49 | 42 |
| PHP 5.5 | 43 | 42 | 35 |
| PHP 5.4 | 41 | 43 | 40 |
| PHP 5.3 | 97 | 83 | 77 |
| PHP 5.2 | 12 | 10 | 10 |
| PHP 5.0 | 2 | 2 | 1 |
Интересная получается картина, с одной стороны, приятно видеть PHP 8.1 как минимальную требуемую версию для 125 пакетов. Однако посмотрите, сколько пакетов по-прежнему требуют версии ниже PHP 8.0: 707 из 926 проанализированных пакетов. Это более 75%!
Да, в качестве примечания: существует всего 926 пакетов, потому что для некоторых из 1000 самых популярных пакетов не требуется версия PHP.
Нанесем эти данные на график:

Ну Вы то уже используете PHP 8.1?)
Аникин


Связаться со мной:
Менеджер версий php для Debian/Ubuntu.
Скрипт мультиверсионности мной более не поддерживается, т.к в новых версиях дебиан все сложнее автоматизировать установку старых версий php. Поэтому php 5 собирайте руками. Либо проходите по ссылке.
Выкладываю мой скрипт который поможет установить несколько версий php из исходных кодов на ваш сервер. Скрипт делался в первую очередь для Debian и проверялся на Debian 8 x64. Но работает и на Ubuntu. Удобно с помощью скрипта поддерживать актуальные версии php на сервере с вестой, т.к скрипт умеет автоматически обновлять шаблоны весты при сборке.
На debian 7/8 с моими флагами установки без проблем собираются php 5.2 и выше.
На ubuntu 14.04/16.04 по умолчанию собираются php 5.3 и выше. 5.2 при компиляции валится с ошибкой. Поэтому если нужен 5.2 юзайте дебиан.
Что делает скрипт:
- При запуске спрашивает какие версии php требуется собрать(версию нужно вводить полностью. Например 7.1.2, а не 7.1. Можно ввести несколько версий через пробел), создавать ли на бинарник php-cgi симлинк в /usr/bin для быстрого доступа. Проверяет наличие на сервере панели vestacp. Если находит её, то спрашивает создавать ли шаблон web для каждой версии.
- При первом запуске спрашивает, нужно ли ставить зависимости. Если вы откажетесь от установки зависимостей, то вам нужно их установить самостоятельно. Иначе при сборке вы получите ошибки. При последующих запусках этот шаг пропускается. Нужно понимать что скрипт старается поставить все возможные зависимости, но в разных дистрибутивах могут использоваться разные пакеты или при использовании кастомных флагов компиляции может потребоваться что-то доустановить.
- Парсит http://php.net/downloads.php и http://php.net/releases/ на наличие bz2 архива с исходниками указанной юзером версии php. Если находит, скачивает и распаковывает исходники в /opt/php/src.
Также можно положить архивы с иходниками в /opt/php/src/bzips, тогда скрипт не будет их скачивать.
- Конфигурит, по умолчанию с моими параметрами компиляции(подойдут для большинства пользователей). Собирает.
Тем кто хочет использовать свои параметры компиляции обязательно кликнуть сюда
Можно свои параметры конфигурирования положить в файл /opt/php/options. Если скрипт находит этот файл, то он использует его для конфигурирования. Свой файл можно сделать на основе моего. Скрипт заменяет version в файле конфигурирования на текущую собираемую версию. Это сделано для того чтобы скрипт автоматом создавал свой каталог для каждой версии. Если вы собираете например версию 5.3.29 и в вашем файле конфигурирования указано prefix=/opt/php/php-version, то это по сути равно prefix=/opt/php/php-5.3.29. При сборке нескольких версий одновременно эту фичу нужно использовать чтобы не собирать все версии в один каталог. - При необходимости создает симлинк и шаблон для весты. Если создает темплейты для весты, то проверяет включен ли модуль cgi в апаче. Если модуль не включен, то включает его.
Запустить скрипт очень просто
# git clone https://github.com/petranikin/mgrvphp.git # cd mgrvphp # bash mgrvphp
Требования
Для работы WordPress рекомендуется хостинг, который поддерживает:
- PHP версии 7.4 или выше.
- MySQL версии 5.7 или выше ИЛИMariaDB версии 10.3 или выше.
- Протокол HTTPS
Это всё, что нужно. В качестве веб-сервера мы рекомендуем Apache или Nginx как наиболее надёжные и функциональные, но в общем случае подойдёт любой сервер с поддержкой PHP и MySQL. Стоит заметить, что мы не можем протестировать все возможные конфигурации на отсутствие проблем.
Для подробных рекомендаций по расширениям PHP посмотрите руководство от команды хостинга.
Замечание: Если на вашем сервере доступны только старые версии PHP и MySQL, WordPress также работает на PHP 7.0+ и MySQL 5.0+, однако поддержка этих версий прекращена, и они могут стать угрозой безопасности вашего сайта.
Спросите у хостинг-провайдера
Вот пример письма, которое вы можете отправить своему хостинг-провайдеру:
- PHP 7.4 или выше
- MySQL 5.7 или выше ЛИБО MariaDB 10.3 или выше
- Nginx или Apache с модулем mod_rewrite
- Протокол HTTPS
Не обязательно, но желательно для повышения безопасности
Хостинг считается более безопасным, когда PHP-приложения, такие как WordPress, запускаются от имени вашей собственной учётной записи, а не от стандартной учётной записи сервера (например, www-data). Спросите своего потенциального хостинг-провайдера, какие шаги они предприняли для обеспечения безопасности вашей учётной записи.
Переход на PHP 8.х в коробочных версиях Битрикс24
В административном интерфейсе коробочных версий продуктов «1С-Битрикс» вы могли заметить такое уведомление:
С 01.02.2023 будет ограничена поддержка наших продуктов на PHP версии ниже 8.0. Рекомендуемая версии PHP – 8.1 или выше. Вы используете версию PHP 7.4.33. Пожалуйста, запланируйте обновление PHP или обратитесь в техническую поддержку вашего хостинга.
Почему важно обновить PHP
Версия PHP 7.х объявлена устаревшей и больше не поддерживается, для неё не выпускаются исправления функциональных ошибок и ошибок безопасности. Использование версий PHP ниже 8 крайне не рекомендовано.
Вы не сможете установить обновления коробочных версий продуктов «1С-Битрикс» для исправления ошибок и получения нового функционала, пока не обновите PHP до минимальной версии 8.0 или рекомендованной 8.1 в своем серверном окружении.
Запланируйте обновление PHP до минимальной версии 8.0 или до рекомендуемой PHP 8.1 в самое ближайшее время.
Как обновить PHP
Обновление версии PHP необходимо произвести поэтапно. Для этого обратитесь к вашему системному администратору или в техподдержку вашего хостинга.
- Обязательно создайте резервную копию вашей установки. Это может быть как резервная копия средствами продукта, так и полностью всего сервера, например виртуальной машины VMBitrix.
- Обновите ядро и все модули продукта до последних доступных версий в разделе Настройки > Marketplace > Обновление платформы.


Если вы используете виртуальную машину VMBitrix, то обновить PHP можно через меню VMBitrix: 1. Manage servers in the pool — 8. Update PHP and MySQL. Подробнее читайте в отдельном курсе.
Куда обращаться в случае ошибок при обновлении версии PHP до 8.х
- Если после обновлений PHP появятся ошибки в работе стандартных модулей продуктов «1С-Битрикс», то обратитесь в Поддержку24. Также по модулям из Маркетплейса, в названия которых содержатся bitrix.* , нужно обращаться в Поддержку24, например:
bitrix.eshop bitrix.sitecommunity bitrix.sitecorporate bitrix.siteinfoportal bitrix.sitepersonal bitrix.learningtemplatesПримеры частых ошибок и их решения
Возможные причины ошибок после обновления до PHP 8.х:
- До перехода на PHP 8.х не было обновлено ядро и все модули продукта до последних доступных версий в разделе Настройки > Marketplace > Обновление платформы.
- До перехода на PHP 8.х не были уставлены обновления сторонних решений (они в названии имеют точку) на странице Marketplace > Обновление решений.
- Разработчик не обновил модуль для поддержки PHP 8.
Основные действия по исправлению ошибок после обновления PHP до 8.х:
- Вернуться на предыдущую версию PHP 7.x, когда все работало, обновить компоненты системы и сторонние модули, а затем повторно обновить версию PHP до 8.х.
- Если предыдущие действия не исправили ошибки, то обратиться к разработчику модуля – смотрите раздел выше Куда обращаться в случае ошибок.
- Временно отключить модуль с ошибкой, переместив его из директории /bitrix/modules .
- Удалить стороннее решение с ошибкой.
Стоить отметить, что в примерах даны лишь решения ошибок для конкретного модуля. Каждая ошибка должна рассматриваться разработчиком индивидуально.
[Ux11] Ошибка описания модуля "name.module". Не установлено соединение с сервером обновлений. [Ux11] Ошибка описания модуля "name.module".
Ошибка может появиться после повышения версии PHP до 8.0 и выше. Сайт при этом работает, но установить или обновить другие решения нельзя, пока сохраняется ошибка.
Решение проблемы:
Исправление в общем случае будет таким: в файле /bitrix/modules//install/index.php код:
function ()
заменить на:
function __construct()
При выполнении скрипта возникла ошибка. Включить расширенный вывод ошибок можно в файле настроек .settings.php.
Решение проблемы:
Подключиться по FTP/SFTP или зайти в панель хостинга, включить вывод ошибок в файле /bitrix/.settings.php :
'debug' => true,
После чего на сайте будет выведен текст ошибки:
Пример ошибки
Non-static method Super\Functions\CSuperModRep::checkBack() cannot be called statically (0) /home/bitrix/modules/super.mod/lib/functions/CSuperModRep.php:52 #0: Super\Functions\CSuperModRep::checkRepActive() /home/bitrix/modules/super.mod/classes/general/CModEvents.php:1621 #1: CModEvents::OnPageStartHandler() /home/bitrix/modules/main/classes/general/module.php:480 #2: ExecuteModuleEventEx(array) /home/bitrix/modules/main/include.php:163 #3: require_once(string) /home/bitrix/modules/main/include/prolog_before.php:14 #4: require_once(string) /home/bitrix/modules/main/include/prolog.php:10 #5: require_once(string) /home/bitrix/header.php:1 #6: require(string) /home/index.php:1В примере видно, что ошибку отдает сторонний метод CSuperModRep::checkBack() решения super.mod.
Исправление в общем случае будет таким: в коде checkBack() нужно правильно объявить статическую функцию:
function checkBack()заменить на:
public static function checkBack()PHP Fatal error: $GLOBALS can only be modified using the $GLOBALS[$name] = $value syntax in /www/bitrix/modules/main/tools.php
Данная ошибка может появиться после повышения версии PHP до 8.x в случае, если не были установлены все доступные обновления платформы на версии PHP 7.x.
Решение проблемы:
Эта ошибка была исправлена в обновлении главного модуля main 22.100.0 .
Поэтому необходимо понизить версию PHP до 7.x, произвести обновление продукта и модулей до последней доступной версии. И только потом повысить версию PHP до 8.х.
[TypeError] call_user_func_array(): Argument #1 ($callback) must be a valid callback, non-static method COMP\BXE\EventHandlers::AdminContextMenuShow() cannot be called statically (0).
Эта ошибка может появиться после повышения версии PHP до 8, но уже не очень очевидна:
Пример ошибки
[TypeError] call_user_func_array(): Argument #1 ($callback) must be a valid callback, non-static method COMP\BXE\EventHandlers::AdminContextMenuShow() cannot be called statically (0) /var/www//bitrix/modules/main/classes/general/module.php:480 #0: ExecuteModuleEventEx /var/www/bitrix/modules/main/interface/admin_ui_list.php:1983 #1: CAdminUiContextMenu->Show /var/www/bitrix/modules/main/interface/admin_ui_list.php:1168 #2: CAdminUiList->ShowContext /var/www/bitrix/modules/main/interface/admin_ui_list.php:630 #3: CAdminUiList->DisplayFilter /var/www/bitrix/modules/iblock/admin/iblock_element_admin.php:5217 #4: include(string) /var/www/bitrix/admin/cat_product_admin.php:3Из текста ошибки сразу не узнать директорию модуля, но данный метод COMP\BXE\EventHandlers::AdminContextMenuShow() принадлежит стороннему модулю.
Решение проблемы:
Исправление в общем случае будет таким: в коде AdminContextMenuShow() нужно правильно объявить статическую функцию:
function AdminContextMenuShow()заменить на:
public static function AdminContextMenuShow()Белый экран после повышения версии PHP до 8.х, а на PHP 7.4 все работает
Такая ошибка может быть из-за того, что в настройках PHP установлен параметр short_open_tag = Off .
Решение проблемы:
- Нужно задать в конфигурационном файле PHP: short_open_tag = On .
- Проверить логи веб-сервера на предмет ошибок и устранить их.
- Также можно просмотреть ошибки на странице сайта с белым экраном: нажать правую кнопку мыши и выбрать Просмотр кода страницы, пролистать страницу вниз и проверить имеются ли ошибки на ней.
