Как безопасно обновить PHP и модули сайта

Пошаговый план для владельцев сайтов и интернет-магазинов, чтобы перейти на поддерживаемую версию без падения витрины и потери продаж

Безопасное обновление PHP начинается с инвентаризации зависимостей и тестового стенда. Резервная копия, контрольные сценарии, окно выпуска и план отката нужны до переключения рабочей версии, а не после ошибки. [8]

Зачем вообще об этом думать

Обычно про версию PHP вспоминают, когда сайт уже перестаёт открываться после автоматического обновления у хостинга, или когда форма заказа внезапно ломается. До этого момента PHP работает «под капотом» и о нём никто не думает — ровно до тех пор, пока версия не перестанет получать патчи безопасности.

Разница между актуальной и устаревшей версией PHP не в скорости и не в новых функциях языка. Разница в том, получает сайт заплатки от новых уязвимостей или нет. Каждая версия PHP получает два года полноценной поддержки — с исправлением багов и уязвимостей, а затем ещё два года только критических патчей безопасности; после этого срока ветка не получает вообще ничего . На середину 2026 года живыми остаются лишь четыре ветки — 8.2, 8.3, 8.4 и 8.5, причём 8.2 доживает последние месяцы поддержки . Всё, что старше, — включая по-прежнему массово используемую PHP 7.4 — эксплуатируется без единого патча уже несколько лет.

Эта статья для тех, кто отвечает за сайт или интернет-магазин: администраторов, технических директоров, владельцев бизнеса, которым разработчик или хостинг сообщил, что «пора обновлять PHP». Разберём, что именно происходит при обновлении, какие риски реальны, а какие преувеличены, и как пройти переход без простоя витрины.

Простыми словами: что такое версия PHP и почему она «устаревает»

PHP — язык программирования, на котором работает серверная часть большинства сайтов: WordPress, 1С-Битрикс, Joomla, самописные CMS. Когда посетитель открывает страницу, именно PHP-код на сервере собирает её из шаблона, базы данных и настроек и отдаёт готовую страницу в браузер.

Разработчики PHP выпускают новую версию раз в год и поддерживают её ограниченное время. «Устаревшая» версия — не значит нерабочая: сайт на PHP 7.4 может открываться и работать годами. Проблема не в работоспособности, а в безопасности: новые уязвимости, которые находят в PHP, для устаревших веток не исправляются никогда — команда разработки PHP их просто не патчит .

Как устроен жизненный цикл PHP

Ветка PHP получает два года активных исправлений и ещё два года только критических обновлений безопасности. После окончания поддержки новые уязвимости этой ветки больше не исправляются. [1][2]

Цель — последняя поддерживаемая ветка, совместимая с CMS, модулями, расширениями PHP и окружением. Выбор подтверждают официальной матрицей совместимости и тестами проекта; номер самой новой ветки без такой проверки не является достаточным основанием. [3][4][5]

Российская специфика

Требования конкретных CMS

Для «1С-Битрикс: Управление сайтом» с 1 февраля 2026 года минимальная версия PHP — 8.2. Производитель рекомендует PHP 8.4 и новее при условии совместимости редакции, модулей и собственного кода. Перед обновлением сверяют актуальные технические требования и выполняют проверку системы в административной панели. [6] [7]

Для других CMS правила отличаются. Сначала проверяют официальную матрицу совместимости ядра и расширений, затем миграционные руководства PHP для всех промежуточных изменений.

Регуляторные требования к управлению обновлениями

Требования к управлению обновлениями зависят от типа информационной системы, обрабатываемых данных и применимых нормативных актов. Для обычного коммерческого сайта корректнее опираться на модель угроз, договорные требования и внутренний порядок управления уязвимостями, не распространяя автоматически специальные правила государственных систем и объектов КИИ.

Практически полезен единый процесс: получать уведомления вендоров, оценивать влияние, проверять подлинность пакета, тестировать изменение, согласовывать выпуск и фиксировать результат. Конкретные обязательные меры определяют с ответственным за информационную безопасность и юристом.

Варианты обновления

Прежде чем переходить к шагам, стоит понимать, из чего вообще выбирать.

• Самостоятельное обновление силами штатного администратора или разработчика. Подходит, если есть тестовая среда, понимание кода сайта и время на постепенное тестирование.
• Обновление силами хостинг-провайдера. Многие хостинги позволяют переключить версию PHP в панели управления за минуты — но это переключение самого интерпретатора, а не проверка кода сайта на совместимость с ним. Переключение без предварительного теста — частая причина аварийных обновлений «по факту поломки».
• Привлечение подрядчика для аудита и обновления. Оправдано для коммерческих сайтов и интернет-магазинов, где простой или сбой оформления заказа напрямую бьёт по выручке, а также когда на сайте накопилось много кастомного кода и сторонних модулей, совместимость которых неочевидна.

Обычно достаточной оказывается комбинация: администратор выполняет плановые шаги по чек-листу, а для сложных участков — code review, специфичные интеграции, highload-компоненты — привлекается разработчик точечно.

Практические этапы безопасного обновления

1. Зафиксировать текущее состояние

Определить точную версию PHP, версию CMS, список установленных модулей, плагинов и сторонних расширений PHP, а также критичные интеграции — платёжные системы, CRM, 1С, службы доставки. Без этой карты сложно понять, что именно может сломаться.

2. Сверить требования CMS и ключевых модулей

Изучить официальную документацию CMS и основных плагинов на предмет минимальной и рекомендуемой версии PHP. Для 1С-Битрикс — воспользоваться встроенным инструментом «Проверка системы», который показывает, какие модули и компоненты, платные и бесплатные, нуждаются в обновлении перед переходом на PHP 8.x.

3. Проверить код и зависимости

Статический анализ и PHPCompatibility помогают найти часть несовместимостей, а composer audit — известные уязвимости установленных пакетов. Эти инструменты дополняют, но не заменяют запуск проекта и контрольные сценарии на целевой версии. [9]

4. Сделать резервную копию и проверить восстановление

Резервная копия должна включать файлы, базу данных и конфигурацию. Критически важно не просто сделать копию, а один раз действительно восстановить из неё тестовую версию сайта — иначе есть риск обнаружить проблему с бэкапом в момент, когда он реально понадобится.

5. Развернуть тестовый стенд с целевой версией PHP

Копия сайта на отдельном окружении (поддомен, staging-сервер, локальный Docker-контейнер) с той версией PHP, на которую планируется переход. Здесь же — обновление зависимостей через Composer, если проект их использует: менеджер зависимостей фиксирует конкретные версии библиотек через composer.lock и предупреждает о неразрешимых конфликтах версий вместо того, чтобы сайт «рассыпался» в проде.

6. Исправить найденные несовместимости

Обновить устаревшие модули и библиотеки, заменить или отключить компоненты без активной поддержки, переписать участки кода, использующие удалённые в новой версии PHP функции.

7. Пройти контрольные сценарии на стенде

Не просто открыть главную страницу, а вручную пройти ключевые бизнес-сценарии: оформление заказа и оплата, отправка формы заявки, авторизация и личный кабинет, поиск и фильтрация каталога, обмен данными с CRM или 1С, отправка почтовых уведомлений.

8. Перенести изменения в боевую среду в согласованное окно

Выполнять перенос в период минимальной нагрузки, заранее предупредив ответственных сотрудников. Иметь готовый и проверенный план отката на случай непредвиденной ошибки.

9. Проконтролировать сайт после переключения

Первые часы и дни после обновления — проверять логи ошибок сервера, скорость ответа страниц и работу тех же контрольных сценариев уже в бою, а не полагаться на то, что раз тестовый стенд прошёл проверку — прод обязательно повторит результат один в один.

Ограничения, типичные ошибки и риски

• Обновление «на глаз», без тестового стенда. Самая частая причина аварийных простоев: переключатель версии PHP в панели хостинга меняет интерпретатор мгновенно, но не проверяет, готов ли к этому код сайта.

Пропуск изменений между ветками. При переходе через несколько версий учитывают все промежуточные migration guides и изменения зависимостей. Последовательно переключать рабочий runtime на каждую ветку необязательно, но совместимость нужно проверить по всей цепочке изменений.

• Забытые сторонние модули без активной поддержки. Платный или бесплатный модуль, автор которого давно не обновляет код под новые версии PHP, — частый источник поломки после, казалось бы, успешного обновления ядра CMS.
• Отсутствие проверки восстановления из бэкапа. Резервная копия, которая ни разу не разворачивалась, — это не гарантия, а предположение.
• Игнорирование продлений лицензий сторонних решений. Для отдельных решений в маркетплейсах CMS обновление до совместимой версии может быть увязано с действующей лицензией — это стоит уточнить заранее, а не в процессе аварийного восстановления.

Как выбрать между самостоятельным обновлением и подрядчиком

Если сайт простой, без кастомной логики и сторонних интеграций — обновление по шагам выше вполне реально выполнить силами штатного администратора. Если это работающий интернет-магазин с оплатой, обменом с 1С, накопленным за годы кастомным кодом и десятками модулей — стоит закладывать участие разработчика хотя бы на этапе аудита совместимости и code review, потому что цена ошибки здесь — это остановленные продажи, а не просто «сайт временно недоступен».

Как может помочь «Пятый фактор»

«Пятый фактор» может провести инвентаризацию зависимостей, развернуть тестовую копию, исправить подтверждённые несовместимости и пройти контрольные сценарии сайта. Выпуск выполняется в согласованное окно с резервной копией и проверенным планом отката.

Вывод

Устаревшая версия PHP — это не абстрактная угроза «на будущее», а конкретный риск здесь и сейчас: часть используемых сегодня версий уже не получает патчей несколько лет, а новые уязвимости в PHP продолжают находить регулярно. При этом само обновление — управляемая, повторяемая процедура: фиксация текущего состояния, проверка требований CMS и модулей, тестовый стенд, статический анализ кода, контрольные сценарии и только затем — перенос в бой с планом отката. Чем раньше начать двигаться по этому плану, тем меньше шанс оказаться в ситуации, когда обновлять PHP приходится в аварийном режиме — когда уже перестала работать оплата или личный кабинет.

Чтобы обсудить задачу или получить консультацию, свяжитесь с командой «Пятого фактора» любым удобным способом.

Источники

[1] PHP — Supported Versions — https://www.php.net/supported-versions.php

[2] PHP — Unsupported Branches — https://www.php.net/eol.php

[3] PHP 8.3 Migration Guide — https://www.php.net/manual/en/migration83.php

[4] PHP 8.4 Migration Guide — https://www.php.net/manual/en/migration84.php

[5] PHP 8.5 Migration Guide — https://www.php.net/manual/en/migration85.php

[6] 1С-Битрикс — технические требования — https://www.1c-bitrix.ru/products/cms/requirements.php

[7] 1С-Битрикс — обновление PHP в BitrixVM — https://dev.1c-bitrix.ru/learning/course/?COURSE_ID=32&LESSON_ID=29266

[8] 1С-Битрикс — резервное копирование — https://dev.1c-bitrix.ru/user_help/settings/tools/backup/index.php

[9] Composer — audit command — https://getcomposer.org/doc/03-cli.md#audit

[10] OWASP Web Security Testing Guide — https://owasp.org/www-project-web-security-testing-guide/