Как выбрать версию PHP для сайта

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

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

В этой статье разберём разницу веб-PHP и CLI, необходимые расширения, проверку Composer, тестирование WordPress и безопасное обновление. Если вы выбираете не только интерпретатор, но и площадку, начните с руководства по PHP-хостингу.

Что меняется вместе с версией PHP

Обновление может затрагивать синтаксис, стандартные функции, обработку типов, сообщения об ошибках, совместимость расширений и производительность. Нельзя считать, что это всегда только «тот же сайт, но быстрее».

У major- и minor-переходов могут быть несовместимые изменения. Даже если главная открывается, ошибка иногда проявляется только при импорте, отправке письма, обработке изображения или выполнении редкого административного действия.

Кроме самого PHP важны расширения: mbstring, intl, curl, драйвер нужной базы, библиотеки изображений и другие компоненты. Их состав определяется приложением. Две площадки с одинаковым номером PHP могут иметь разный набор возможностей.

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

Как устроена поддержка PHP

У веток PHP есть периоды активной поддержки и исправления проблем безопасности. После завершения официальной поддержки новые исправления проекта для этой ветки не выпускаются в обычном порядке.

Актуальный перечень и даты опубликованы на странице Supported Versions. Проверяйте её в момент выбора, а не ориентируйтесь на скриншот многолетней давности или наличие пункта в панели хостинга.

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

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

Откуда брать требования сайта

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

Если проект использует Composer, посмотрите composer.json и composer.lock. В первом описаны ограничения, во втором зафиксированы выбранные версии зависимостей. Не запускайте composer update на рабочем сайте только ради проверки PHP: команда может изменить набор пакетов.

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

Для WordPress отдельно проверьте требования текущего ядра, активной темы и каждого существенного плагина. Магазину на WooCommerce нужна проверка оформления заказа и платежей, а не только редактора записей. Особенности размещения такого проекта рассмотрены в руководстве по хостингу для магазина.

Как узнать текущую версию

Самый простой путь — настройки сайта в панели хостинга и раздел состояния CMS. Запишите не только номер, но и обработчик, выбранный профиль и доступные расширения.

В командной строке:

php -v
php --ini
php -m

Эти команды показывают версию CLI, используемые конфигурационные файлы и список расширений для этого запуска. Веб-сайт может работать через другой бинарный файл и другой php.ini.

Не оставляйте публичную страницу phpinfo() после проверки. Она раскрывает много деталей окружения. Если нужна диагностика веб-обработчика, используйте закрытый раздел CMS или временный минимальный скрипт с ограничением доступа, затем удалите его.

Поведение командной строки описано в руководстве PHP CLI. Для прикладной проверки важно сравнить обе среды, особенно если сайт работает, а cron падает, или наоборот.

Почему веб-сайт и cron могут использовать разный PHP

Панель часто переключает версию только для конкретного сайта. Задание cron с командой php script.php продолжает использовать интерпретатор, найденный в PATH. Он может отличаться от веб-версии.

Поэтому найдите все фоновые команды и уточните полный путь к нужному PHP. На разных хостингах он различается. Не копируйте путь вроде /usr/bin/php8.x без проверки, существует ли такой бинарный файл на вашей площадке.

Проверьте также Composer, очереди и обработчики импорта. Если процесс живёт долго, он может продолжать работать на старом окружении до перезапуска. На управляемом хостинге способ такого перезапуска определяет провайдер.

Для воспроизводимости полезно записать: версия веб-PHP, версия CLI, конфигурационный профиль, расширения и команды планировщика. Тогда следующее обновление не начнётся с повторного поиска того, что именно работает в проекте.

Проверка Composer без изменения зависимостей

На подготовленной копии проекта с установленными зависимостями выполните:

composer check-platform-reqs --no-dev

Команда проверяет требования установленных production-пакетов к реальной платформе. Она помогает обнаружить неподходящую версию PHP или отсутствующее расширение. Подробности — в документации Composer.

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

Не используйте --ignore-platform-reqs как способ решить несовместимость рабочего проекта. Этот параметр позволяет обойти проверку, но не добавляет недостающую функцию и не делает код совместимым.

Если разработчик задаёт config.platform в Composer, различайте моделируемую платформу при разрешении зависимостей и фактическую среду выполнения. Важно проверить именно ту среду, в которой сайт будет работать.

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

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

Для нового проекта обычно удобнее современная поддерживаемая ветка, которую допускает весь стек. Для существующего сайта иногда разумнее промежуточный переход: сначала обновить устаревшие расширения, затем испытать более новую среду.

Не выбирайте версию только по синтетическому тесту производительности. Реальная скорость зависит от кода, базы, кеша и внешних запросов. Сайт, который большую часть времени ждёт сторонний API, может почти не ускориться от одного обновления интерпретатора.

Составьте простую матрицу:

Решение принимается по совместимости и сроку жизни, а не по максимальному номеру в выпадающем списке.

Подготовка тестовой копии

Сделайте резервную копию файлов и базы и проверьте восстановление. Затем разверните копию в отдельной папке, базе и окружении. Нельзя тестировать обновление на той же базе, которую использует рабочий сайт.

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

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

Для проверки под настоящим доменным именем можно использовать локальное направление запросов на тестовый сервер. Метод описан в статье как проверить сайт перед переключением DNS.

Что проверять на копии

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

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

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

Проверьте фоновые задания в том же окружении, в котором они будут выполняться после переключения. Успешный ручной запуск из SSH с другой версией PHP не подтверждает исправность cron.

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

Сообщение Deprecated обычно сообщает об устаревающем способе работы, а Fatal error — об ошибке, которая остановила выполнение. Но приоритет определяется не одним словом: предупреждение может засорять журнал и указывать на будущую проблему, а фатальная ошибка в редком задании — незаметно ломать важную функцию.

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

Официальные migration guides описывают изменения между ветками; пример — переход с PHP 8.3 на 8.4. Для другого перехода используйте соответствующее руководство, а не список изменений случайной версии.

Если плагин не поддерживается, оцените замену или разработку исправления. Постоянное сохранение устаревшего PHP ради одного заброшенного компонента обычно усложняет обслуживание всего проекта.

Как переключить рабочий сайт

Выберите окно низкой активности и ещё раз сохраните актуальную копию. Зафиксируйте прежнюю версию и профиль настроек. Убедитесь, что в панели можно вернуть прежнее значение, а при необходимости восстановить файлы и базу.

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

После применения очистите или обновите кеш штатным способом, если это требуется приложению. Перезапуск обработчиков выполняйте средствами панели или сервера. Не удаляйте каталог сессий и все временные файлы без разбора.

Сразу пройдите короткую приёмку: главная, внутренняя страница, вход, форма, загрузка и ключевая операция проекта. Затем проверьте журналы и ближайшее выполнение cron. Отдельно убедитесь, что мониторинг не продолжает проверять только закешированную страницу.

Когда и как возвращаться назад

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

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

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

Если старая версия уже не поддерживается, откат — временная мера для восстановления работы, а не окончательное решение. Запланируйте устранение несовместимости с понятным сроком и ответственным.

Настройки, которые нужно перепроверить после обновления

Если после переключения перестала загружаться обложка, не спешите возвращать весь проект. Сначала сравните размер запроса, лимиты, расширения изображений и права временной папки. Если ошибка блокирует работу, восстановите прежнее окружение, а диагностику продолжите на копии.

Когда смена хостинга действительно нужна

Если провайдер не предоставляет поддерживаемую версию, нужное расширение или раздельные настройки сайтов, это ограничение площадки. Но сначала уточните возможности тарифа и планы обновления у поддержки.

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

Сравните требования приложения с возможностями услуги. При необходимости используйте Hostfera Select для первичного выбора типа инфраструктуры, а перенос выполняйте по проверенному порядку.

Пример обновления небольшого сайта на WordPress

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

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

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

Если всё работает, фиксируют настройки и назначают рабочее окно. В момент переключения выполняют свежую копию, меняют версию только нужного сайта и повторяют короткую приёмку. На следующий день проверяют, что ночные задания завершились, а журнал не наполнился новыми предупреждениями.

В этом примере нет обещания, что любой WordPress совместим с конкретной веткой: результат определяется реальным набором компонентов. Именно поэтому тестовая копия полезнее универсального списка «рекомендуемых версий» без привязки к проекту.

Пример для собственного приложения с Composer

У приложения есть репозиторий, composer.lock и очередь фоновых задач. Разработчик собирает копию с зафиксированными production-зависимостями, а не обновляет их до случайных последних версий. Затем проверяет платформенные требования и запускает прикладные тесты на выбранном PHP.

Отдельно проверяется сборка: инструменты разработки могут иметь другие требования, чем само приложение. Если сборка выполняется в отдельном окружении, это нужно описать, а не пытаться запускать её на любом сервере с подходящим веб-PHP.

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

Если тесты проходят, сравнивают производительность на одинаковом сценарии. Не стоит принимать решение по одному запуску с холодным кешем на старой версии и прогретым на новой. Сохраняют несколько результатов и проверяют разброс.

Почему настройки OPcache требуют отдельного внимания

OPcache хранит подготовленный код и помогает избежать повторной работы интерпретатора. Но его настройки должны соответствовать процессу развёртывания. Если проверка изменений файлов ограничена, после обновления кода может понадобиться предусмотренный процессом сброс или перезапуск.

Не копируйте большие значения памяти из чужого VPS в небольшой общий аккаунт. Доступные ресурсы и область действия настроек отличаются. На виртуальном хостинге часть параметров управляется провайдером.

Если после обновления вы видите старую логику, проверьте не только браузерный кеш, но и кеш приложения, OPcache и долгоживущие процессы. При этом не начинайте с удаления всех временных каталогов: сначала установите, какой слой хранит прежнее состояние.

Проверка загрузок и обработки изображений

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

Проверьте поддержку форматов библиотекой изображений. Наличие самого расширения не всегда означает одинаковый набор возможностей его сборки. Если сайт создаёт WebP, проверьте реальное сохранение и открытие результата.

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

Как составить паспорт PHP-окружения

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

Пароли базы и API-ключи в такой паспорт не включают. Для них нужен отдельный защищённый механизм доступа. В документе достаточно указать, где ответственный получает секреты безопасным способом.

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

Частые вопросы

Всегда ли новая версия PHP быстрее?

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

Можно ли оставить старую версию, если сайт работает?

Работоспособность не равна поддержке безопасности. Проверьте официальный статус ветки и условия провайдера. Устаревшее окружение требует плана обновления, даже если ошибка пока не проявилась.

Достаточно ли сменить версию в панели?

Для совместимого проекта это может быть основным действием, но после него нужно проверить расширения, лимиты, веб-сценарии, cron и журналы. Сама панель не тестирует прикладную логику.

Нужно ли обновлять все сайты аккаунта одновременно?

Лучше проверять каждый проект отдельно и использовать раздельные настройки, если они доступны. Разные CMS и расширения могут иметь разные требования.

Что делать, если нет тестового поддомена?

Можно развернуть копию локально или на отдельной площадке, сохранив ключевые характеристики окружения. Для проверки нового хостинга под настоящим именем используйте локальное переопределение DNS, не затрагивая посетителей.

Как оценить результат через несколько дней

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

Сравните объём новых ошибок и предупреждений с исходным периодом. Увеличившийся журнал может говорить о несовместимом компоненте, даже если посетители пока не жалуются. Не скрывайте предупреждения только ради чистой статистики: сначала установите их источник.

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

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

Контрольный список

• Проверен статус поддержки выбранной ветки PHP.

• Сверены требования CMS, темы, расширений и зависимостей.

• Различаются веб-PHP и CLI, известны команды cron.

• Создана независимая копия и тестовое окружение.

• Пройдены критичные сценарии и проверены журналы.

• Сохранены прежние настройки и подготовлен возврат.

• После переключения проверены формы, загрузки и фоновые задачи.

Выбор версии PHP становится предсказуемым, когда он опирается на совместимость и проверку. Номер версии — лишь часть решения; исправно работающий проект требует согласованного окружения и понятного процесса обновления.