Как обновить PHP на сайте: совместимость, расширения и проверка после смены версии
Чтобы обновить PHP на сайте, недостаточно выбрать другую цифру в панели хостинга. Нужно проверить совместимость приложения, перенести необходимые настройки, испытать рабочие сценарии и подготовить возврат к согласованному состоянию. После непроверенного перехода главная страница может открываться, а отправка формы, обработка платежа или ночное задание — завершаться ошибкой.
Этот план подходит для разных CMS и собственных приложений. Он разделяет подготовку кода, смену окружения и проверку результата. Конкретные действия в панели зависят от провайдера, а требования — от установленной версии CMS и её компонентов. Примеры ниже учебные; порядок переключения согласуйте с ответственным за поддержку проекта.
1. Выберите поддерживаемую и совместимую ветку
По официальной таблице поддержки PHP на 1 ноября 2026 года действуют следующие сроки. Активная поддержка включает обычные исправления и исправления безопасности; следующий период ограничен критическими проблемами безопасности.
| Ветка | Состояние на указанную дату | Активная поддержка до | Поддержка безопасности до |
|---|---|---|---|
| 8.2 | Только безопасность | 31.12.2024 | 31.12.2026 |
| 8.3 | Только безопасность | 31.12.2025 | 31.12.2027 |
| 8.4 | Активная поддержка | 31.12.2026 | 31.12.2028 |
| 8.5 | Активная поддержка | 31.12.2027 | 31.12.2029 |
Перед реальным переходом снова откройте эту страницу: таблица отражает состояние на конкретную дату. Выбирайте ветку, которую поддерживают CMS, расширения и библиотеки проекта, затем актуальный исправленный выпуск внутри неё. Самая новая доступная версия не становится автоматически подходящей для установленного приложения.
Если обязательный компонент пока совместим только с более старой поддерживаемой веткой, зафиксируйте ограничение и срок следующего пересмотра. План должен объяснять, что мешает дальнейшему переходу и кто отвечает за обновление этого компонента.
2. Определите PHP отдельно для сайта, CLI и заданий
На одном хостинге приложение может запускаться несколькими способами. HTTP-запросы обрабатывает, например, PHP-FPM, административные команды выполняются через CLI, а расписание использует указанный в задании исполняемый файл. По документации PHP о SAPI, интерфейс выполнения имеет собственное обозначение, включая cli и fpm-fcgi.
| Контекст | Что зафиксировать |
|---|---|
| Сайт через HTTP | Фактическую версию, обработчик домена, расширения и настройки |
| CLI и Composer | Исполняемый файл PHP и используемые файлы конфигурации |
| Cron и воркеры | Команду запуска, пользователя, окружение и работающую версию |
Получите сведения через закрытый отчёт CMS, средства панели или согласованную диагностику администратора. Номер в настройке домена полезен, но результат нужно подтвердить в самом HTTP-обработчике. Вывод версии в терминале подтверждает только тот PHP, который запущен этой командой.
Проверьте поддомены и дополнительные сайты аккаунта. Уточните у хостинга, распространяется ли переключение на один домен, каталог или весь аккаунт. Это определяет объём испытаний и предотвращает неожиданное изменение другого проекта.
Посмотрите, что именно делает расписание. Одно задание запускает PHP напрямую, другое обращается к URL, третье вызывает оболочку со своими переменными окружения. Для каждого установите фактический путь выполнения. Проверка интерактивного терминала не подтверждает окружение задания, которое работает под другим пользователем или с другим рабочим каталогом.
3. Соберите требования всех компонентов
Совместимость сайта с PHP определяется всей установленной системой. Проверьте ядро CMS, тему или шаблон, плагины, платёжный модуль, интеграцию с учётной системой, генератор документов и собственные доработки. Отметка о поддержке новой ветки у CMS не распространяется автоматически на сторонний модуль.
Для каждого обязательного компонента запишите установленный выпуск, поддерживаемые версии PHP, источник требований и нужное действие. Минимальная версия показывает нижнюю границу, но не подтверждает работу на любой более новой. Обращайте внимание и на ограничения сверху, и на замечания разработчика о конкретном выпуске.
Если сначала требуется обновление CMS или библиотеки, подготовьте его как отдельное проверяемое изменение. Уточните, может ли обновлённый код работать на текущем PHP. Когда это возможно, такая последовательность упрощает поиск причины: сначала подтверждается совместимый код, затем меняется среда выполнения.
Для закрытых или закодированных модулей проверьте поддержку загрузчика и наличие подходящей сборки у хостинга. Если обязательный модуль не имеет совместимого выпуска, согласуйте замену или другой целевой вариант до переключения рабочего сайта.
Храните выводы в простой ведомости: компонент, версия, подтверждённая ветка PHP, необходимое изменение, ответственный и проверяемый сценарий. Если сведений о собственной доработке нет, ставьте задачу на испытание. Отсутствие явного запрета в описании модуля не заменяет подтверждения совместимости его установленного выпуска.
4. Прочитайте руководства по всем пересекаемым веткам
При переходе с PHP 8.2 на 8.5 изменения накапливаются. Изучите руководства для PHP 8.3, PHP 8.4 и PHP 8.5, особенно разделы о несовместимых изменениях и устаревающих возможностях. Для более старой исходной версии список начинается раньше.
Выпуск можно планировать сразу на выбранной целевой ветке, если проверены все относящиеся к проекту изменения. Последовательное чтение руководств не требует обязательно запускать каждую промежуточную версию на рабочем сайте.
Например, в PHP 8.5 функция curl_close() отмечена как устаревшая в официальном перечне изменений. Это не равнозначно удалению функции, но помогает найти библиотеку или собственный код, которому требуется обновление. Не применяйте массовые замены по одному совпадению строки без проверки поведения.
Разделяйте предупреждение об устаревании, ошибку выполнения и неверный бизнес-результат. На тестовой копии собирайте диагностические сообщения, связывайте их с компонентом и сценарием. Скрытие предупреждений в интерфейсе не подтверждает, что причина устранена.
5. Сохраните воспроизводимые зависимости и проверьте платформу
Если проект использует Composer, сохраните согласованные composer.json и composer.lock. Согласно документации install, при наличии lock-файла устанавливаются зафиксированные версии зависимостей. Команда update заново разрешает зависимости и меняет lock-файл, поэтому случайный запуск на рабочем сайте смешает обновление PHP с незапланированным изменением библиотек.
Нужные обновления зависимостей подготовьте и проверьте заранее, затем переносите тот же проверенный набор штатным способом проекта. Установка без ошибок ещё не заменяет испытание приложения. Не используйте --ignore-platform-reqs как исправление несовместимости: обход проверки не добавляет отсутствующее расширение и не меняет возможности интерпретатора.
Настройка config.platform позволяет Composer учитывать заданную платформу при подборе пакетов. Она не устанавливает PHP и не доказывает наличие нужного окружения на хостинге.
Для проверки фактического PHP и расширений предназначена check-platform-reqs; она игнорирует подстановку config.platform. Запускайте проверку в подготовленном окружении выбранным интерпретатором. Её успешный результат относится к этому CLI-контексту: расширения и конфигурацию HTTP-обработчика нужно подтвердить отдельно.
При отсутствии SSH согласуйте сборку зависимостей на отдельной площадке и доставку готового выпуска средствами проекта. Требования этой сборки должны соответствовать целевому хостингу. Не заменяйте проверку переносом случайной папки vendor с рабочего компьютера: зафиксируйте её происхождение, lock-файл и результаты испытаний приложения с этим набором.
6. Сверьте расширения, ini и обработчик
Составьте список расширений, которые действительно нужны проекту: драйвер базы, средства работы со строками, изображениями, XML, архивами и внешними HTTPS-запросами. Это перечень для сверки, а не универсальная команда включить все модули. Проверьте доступность и совместимую версию каждого обязательного расширения в целевом окружении.
Сравните существенные настройки: ограничения памяти и загрузки файлов, часовой пояс, хранение сессий, временные каталоги и журналирование. PHP может читать основной и дополнительные ini-файлы, поэтому одного найденного php.ini недостаточно для описания итоговой конфигурации.
Старую конфигурацию переносите осмысленно. Например, в PHP 8.5 удалена директива disable_classes, а OPcache встроен в PHP и всегда загружен; его использование по-прежнему регулируется соответствующими настройками. Такие изменения требуют проверки прежних директив и способа подключения модулей.
Уточните, сохраняются ли после смены обработчика права на файлы, доступ к сокету базы, каталогам сессий и временным данным. Ошибка записи после перехода может быть связана с окружением процесса, хотя синтаксис приложения полностью совместим.
Проверьте настройку вывода ошибок и место записи журнала. На рабочем сайте технические сообщения должны попадать в предусмотренный журнал, не смешиваясь с JSON или содержимым страницы для посетителя. Одновременно убедитесь, что журнал действительно обновляется и доступен ответственному сотруднику: отсутствие видимых сообщений не равно отсутствию ошибок.
7. Подготовьте копию, которую можно восстановить
Резервная копия должна охватывать код, зависимости, конфигурацию, базу и загруженные файлы в согласованном состоянии. Сохраните отдельно сведения о текущем PHP, обработчике, расширениях и расписании. Наличие архива без понятного способа восстановления не делает переключение обратимым.
Проверьте восстановление на отдельной площадке: приложение запускается, подключается к нужной копии базы, видит файлы и позволяет войти тестовому пользователю. Зафиксируйте, кто восстановит систему и сколько времени заняла репетиция. Доступ к панели и резервным данным должен оставаться доступным при отказе самого сайта.
Заранее выясните, можно ли вернуть прежнюю версию PHP на выбранном тарифе. Если провайдер удалит старый обработчик одновременно с обновлением, кнопка переключения назад не будет надёжным планом. Согласуйте доступный вариант восстановления до начала окна работ.
Отдельно определите судьбу новых заказов и файлов, появившихся после резервирования. Возврат старой базы поверх текущей способен потерять эти изменения, даже если страница после восстановления снова открывается.
8. Повторите переход на тестовой копии
Подготовьте окружение, похожее на рабочее по версии PHP, расширениям, обработчику и существенным настройкам. Копия только исходных файлов на ноутбуке не проверяет особенности хостинга. Отметьте различия, которые невозможно воспроизвести, и назначьте для них отдельную проверку.
Изолируйте тестовую базу, очереди, хранилище и ключи внешних сервисов. Почта должна уходить в тестовый приёмник, платежи — в поддерживаемую песочницу. Обычная копия сайта с рабочими секретами способна отправить настоящее уведомление или изменить данные интеграции при запуске задания.
Сначала подтвердите исходное поведение на старом PHP, затем выполните подготовленный переход и повторите те же сценарии. Если вместе меняются код и настройки, фиксируйте каждый шаг. Это позволит отличить давно существовавший дефект от проблемы новой ветки.
Доступ к копии ограничьте, данные для испытаний подготовьте заранее. После репетиции сохраните проверенный состав выпуска и результаты: рабочая публикация должна повторять этот состав, а не собирать новые версии зависимостей в последний момент.
Пройдите на копии и обратный путь, если он предусмотрен планом. Верните согласованную комбинацию PHP, кода и настроек, затем проверьте чтение данных, созданных во время испытания. Такая репетиция показывает, остаётся ли старое приложение совместимым с новым состоянием системы, а не только со старым резервным архивом.
9. Проверяйте результат действий, а не только страницы
Составьте небольшой набор сценариев по важным функциям сайта. Для каждого задайте ожидаемый результат и способ подтверждения. HTTP 200 или открывшаяся форма показывают лишь часть пути: ошибка может возникнуть при сохранении, внешнем запросе или фоновой обработке.
| Сценарий | Что подтвердить |
|---|---|
| Вход и личный кабинет | Сессия сохраняется, права пользователя соблюдаются |
| Форма и вложение | Запись создана, файл сохранён, тестовое уведомление получено |
| Корзина и заказ | Сумма, валюта и состав совпадают с ожидаемыми |
| Платёж в песочнице | Обработан результат провайдера, повтор не дублирует действие |
| Импорт, cron, очередь | Задание выполнено нужным PHP, результат сохранён один раз |
Добавьте функции, зависящие от расширений: создание изображения, чтение XML, формирование документа или подключение к внешнему API. Проверяйте и отказ: неправильные данные должны давать ожидаемое сообщение, а не аварийное завершение.
Автоматические проверки помогают повторить сценарии, но их наличие не освобождает от просмотра журналов. Новый поток предупреждений или исключений требует разбора даже при внешне исправной странице.
Сохраняйте короткое свидетельство результата: идентификатор тестовой заявки, запись выполненного задания, статус тестового платежа. Если ошибка воспроизводится и до обновления, отметьте её отдельно и оцените влияние на приёмку. Это позволяет обсуждать конкретное изменение поведения, не приписывая новой версии каждый найденный дефект проекта.
10. Запланируйте смену версии на хостинге
На виртуальном хостинге без root используйте поддерживаемый провайдером механизм выбора PHP. Заранее выясните область действия настройки, доступные расширения, порядок применения изменений и способ возврата. Если отдельные параметры недоступны, отправьте поддержке конкретный список требований проекта.
Выберите окно, в котором команда сможет проверить результат и принять решение. Назначьте исполнителя, проверяющего и человека с полномочием остановить переход. В плане должны быть указаны целевая ветка, проверенный выпуск приложения, затрагиваемые домены и порядок работы с расписанием.
Учитывайте текущие запросы и задания. Способ завершения работающих процессов и запуска новых согласуйте с хостингом или администратором. Длительно работающий воркер не меняет интерпретатор только от изменения настройки будущих запусков.
Перед началом сохраните текущие параметры панели и состояние важных заданий. Задайте момент, до которого команда принимает решение о продолжении или возврате. Если критический сценарий остаётся непроверенным, не завершайте окно работ формальной отметкой об успехе: назначьте конкретное действие и ответственного за подтверждение результата.
После переключения подтвердите фактическую версию через HTTP, затем отдельно проверьте команды расписания и фоновые процессы. Не считайте изменение селектора в панели достаточным свидетельством завершённого перехода.
11. Проверьте окружение сразу и после фонового цикла
Сначала повторите короткий набор критических сценариев и посмотрите новые записи журналов. Сопоставьте время переключения с первыми ошибками, состоянием очереди и результатами внешних интеграций. Проверяйте конкретную версию выпуска, чтобы устаревший кеш не скрывал фактическую работу нового кода.
Затем дождитесь выполнения заданий, которые запускаются позже. Если импорт работает раз в час, несколько минут исправной главной страницы ничего не говорят о его совместимости. Срок наблюдения определяйте по расписанию и важным пользовательским сценариям проекта.
Учебный пример: сайт перевели на PHP 8.5, но cron сохранил прежний путь к PHP 8.3. Новая библиотека требует более свежую ветку, поэтому HTTP-сценарий работает, а ночная обработка завершается ошибкой. Проверка фактического интерпретатора задания объясняет расхождение быстрее, чем повторное переключение домена.
Сравните не только число ошибок, но и полезный результат: заявки появляются, файлы доступны, задания заканчиваются. Общая тишина в журнале при остановившемся расписании не означает, что обновление прошло успешно.
12. Разделите возврат PHP и восстановление данных
Заранее определите причины остановки: обязательное расширение недоступно, критический сценарий не проходит, появились повреждения данных или неконтролируемые повторы действий. Решение должно опираться на согласованные признаки, а не на готовность терпеть ошибку до конца рабочего дня.
Если менялись только PHP и настройки, прежний код и данные могут оставаться совместимыми со старым окружением. Тогда возврат включает обработчик, необходимые расширения и конфигурацию, после чего результат снова проверяют. Если менялся код, потребуется согласованный комплект приложения и зависимостей для прежнего PHP.
Обновление CMS могло выполнить миграцию схемы или преобразование данных. В такой ситуации переключение интерпретатора назад не отменяет изменения базы. Нужен заранее испытанный вариант: совместимый возврат выпуска, отдельная обратная миграция или исправление с сохранением новой схемы.
Не восстанавливайте старую базу поверх новых заказов без учёта появившихся данных. Уже отправленное письмо, выполненный платёж или внешняя операция также не исчезают после возврата файлов. Перед повторным запуском обработки установите, какие действия успели завершиться.
13. Закройте переход проверяемым результатом
Обновление принято, когда нужная версия используется всеми запланированными контекстами, обязательные расширения и настройки подтверждены, а критические сценарии и фоновые задания выполняются. Сохраните версию PHP, состав приложения, дату переключения, найденные ограничения и результаты приёмки.
Обновите технический паспорт и инструкции запуска заданий. Удалите временные диагностические материалы предусмотренным способом, назначьте дату следующей проверки поддержки ветки. Для оставшихся предупреждений создайте конкретные задачи с ответственными: успешный переход не должен превращать известную несовместимость в забытый долг.
Зафиксируйте и состояние плана возврата после приёмки. Со временем новые данные и изменения кода могут закрыть прежнюю возможность отката, поэтому её нельзя считать бессрочной только потому, что исходный архив сохранился.
Дополните проверку после обновления PHP внешним наблюдением за HTTP-доступностью сайта через SiteGuard. Работу форм, платежей и фоновых задач проверяйте по результатам сценариев и журналам приложения.