
Если сайт магазина работает на PHP 8.2 или старше, PHP стоит обновить до 8.3 или 8.4. По графику php.net поддержка безопасности PHP 8.2 заканчивается 31 декабря 2026 года, а PHP 8.1 уже не поддерживается с 31 декабря 2025 года. После этой даты исправлений уязвимостей для ветки не будет.
Сайт 1 января не упадёт. Риск в другом: смена версии PHP ломает код тихо. Главная страница открывается, а корзина, оплата, обмен с 1С или письма о заказе перестают работать. Поэтому обновление нужно проводить как релиз: копия сайта, проверка сценариев покупки, переключение в спокойное окно и наблюдение за заказами после. До «Чёрной пятницы» и новогоднего пика осталось мало времени, так что начать проверку стоит на этой неделе.
У PHP понятный цикл поддержки. Каждая ветка два года получает обычные исправления и ещё два года только исправления безопасности. После этого ветка уходит в конец жизни. Страница поддерживаемых версий php.net прямо пишет, что пользователям таких версий нужно обновиться как можно скорее, иначе сайт может остаться с неисправленными уязвимостями.
Даты на 11 ноября 2026 года по php.net:
Что говорят платформы:
Для владельца магазина это значит простую вещь: окно, в котором PHP 8.2 ещё получает исправления, закрывается через семь недель. И эти семь недель приходятся на самый нагруженный сезон.
Варианты, от простого к техническому:
Если у магазина несколько сайтов или поддоменов, проверьте каждый. Версия PHP часто задаётся отдельно для каждого сайта.
Для WordPress и WooCommerce разумный выбор — PHP 8.3 или 8.4: обе есть в рекомендациях, WooCommerce протестирован до 8.4. PHP 8.4 поддерживается на год дольше.
Для 1С-Битрикс целевую версию стоит согласовать с подрядчиком после обновления ядра и модулей: требования Битрикса указывают только минимум. Порядок такой: сначала обновить платформу и модули, потом PHP. Подробно про обновление Битрикса — в статье «Обновление 1С-Битрикс без поломки магазина».
Прыгать сразу через несколько версий (с 7.4 на 8.4) можно, но проверять тогда придётся больше. Изменения каждой ветки описаны в руководствах по миграции на php.net: разделы «Backward Incompatible Changes» и «Deprecated Features».
Ядро WordPress и WooCommerce совместимо с новыми версиями PHP. Ломаются обычно:
Пример изменения, которое ломает старый код. В PHP 8.4 объявлен устаревшим неявно допускающий null параметр: запись function foo(T1 $a = null) нужно заменить на ?T1 $a = null. Устаревание само сайт не роняет, но засоряет логи предупреждениями. А несовместимые изменения из раздела «Backward Incompatible Changes» уже могут вызвать фатальную ошибку.
Сделайте копию сайта и базы, включите на ней новую версию PHP и пройдите путь покупателя целиком:
Параллельно смотрите журнал ошибок PHP. Каждое новое предупреждение запишите и решите, что с ним делать: обновить плагин, заменить его или исправить код.
Не переключайте PHP за несколько дней до распродажи и во время неё. Выберите час с наименьшим числом заказов, предупредите менеджеров и подрядчика. Заранее договоритесь, кто и как вернёт прежнюю версию, если что-то пойдёт не так. На большинстве хостингов это одна настройка, и откат занимает минуты.
Сразу после смены версии пройдите тот же сценарий, что на копии, только с реальной оплатой на небольшую сумму. Затем в течение суток сравнивайте число заказов и оплат с обычным уровнем для этого времени. Тихая поломка выглядит так: сайт открывается, а заказов нет. Как её поймать — в статье «Магазин работает, а заказов нет». Если после переключения появилась ошибка 500, начните с журнала ошибок: разбор есть в статье «Ошибка 500 на сайте».
| Риск | Кто отвечает | Как проверить | Когда |
|---|---|---|---|
| Устаревший плагин или модуль падает на новой версии | Подрядчик или разработчик | Журнал ошибок PHP на копии, проход по сценарию покупки | До переключения |
| Платёжный модуль не создаёт платёж или не принимает уведомление об оплате | Подрядчик + менеджер магазина | Тестовая оплата, сверка статуса заказа с личным кабинетом эквайринга | На копии и сразу после переключения |
| Не уходят письма о заказе | Подрядчик | Тестовый заказ, письмо дошло во входящие | Сразу после переключения |
| Сломан обмен с 1С или выгрузка фидов | Подрядчик + ответственный за 1С | Ручной запуск обмена, сверка остатков и цен | В первый день после переключения |
| Не выполняются задания по расписанию | Подрядчик | Время последнего запуска заданий | В первые сутки |
| Падение числа заказов без явной ошибки | Владелец или e-commerce-менеджер | Сравнение заказов с тем же днём недели прошлых недель | Первые 1–3 дня |
| Сайт остался на версии без исправлений безопасности | Владелец | Версия PHP в панели хостинга | Раз в квартал |
ОБНОВЛЕНИЕ PHP: ЧЕК-ЛИСТ МАГАЗИНА
Подготовка
[ ] Текущая версия PHP: ____ (сайт), ____ (поддомены)
[ ] Версия CMS: ____ Целевая версия PHP: ____
[ ] Список плагинов/модулей с версиями и датой последнего обновления
[ ] CMS, плагины и модули обновлены до актуальных версий
[ ] Свежая резервная копия файлов и базы, проверено восстановление
Проверка на копии (новая версия PHP)
[ ] Каталог, поиск, фильтры, карточка товара
[ ] Корзина, промокод, расчёт доставки
[ ] Оформление заказа и тестовая оплата
[ ] Письмо покупателю и уведомление менеджеру
[ ] Вход, регистрация, восстановление пароля
[ ] Админка: товар, статус заказа
[ ] Обмен с 1С, выгрузка фидов, задания cron
[ ] Журнал ошибок PHP просмотрен, предупреждения разобраны
Переключение
[ ] Окно выбрано (не в неделю распродажи): ____
[ ] Ответственный за откат: ____ Способ отката: ____
[ ] Менеджеры предупреждены
После переключения
[ ] Реальный заказ с оплатой на малую сумму прошёл
[ ] Письма о заказе дошли
[ ] Обмен с 1С отработал
[ ] Заказы за сутки сравнены с обычным уровнем
[ ] Дата следующей проверки версии PHP: ____
Это условный пример, он показывает порядок действий, а не реальный случай.
Магазин одежды на WooCommerce работает на PHP 8.1. Владелец открывает «Здоровье сайта» и видит предупреждение об устаревшей версии PHP. Студия на поддержке делает копию сайта и включает на ней PHP 8.4.
Каталог и корзина работают. Тестовая оплата проходит, но в журнале ошибок появляется фатальная ошибка в старом плагине расчёта доставки, который не обновлялся несколько лет. Покупатель на этом шаге видел бы пустой список способов доставки.
Студия находит обновлённую альтернативу плагину, настраивает её на копии и снова проходит сценарий целиком. Переключение назначают на вторник, 7 утра, за полторы недели до распродажи. После переключения менеджер оформляет реальный заказ, сверяет письмо и статус оплаты. Весь день студия сравнивает поток заказов с прошлым вторником.
Без проверки на копии ошибку нашли бы покупатели. Сайт открывался бы, страница оформления загружалась бы, а заказы не создавались бы.
Честные ограничения. Новая версия PHP закрывает уязвимости самого PHP, но не делает сайт безопасным целиком: плагины, пароли и доступы нужно проверять отдельно. Чек-лист в статье не заменит проверку кода, если у магазина много доработок. А если подрядчик не может назвать версию PHP и список модулей, начните с этого вопроса. Полный список проверок после любого изменения на сервере есть в статье «Что проверить после релиза сайта».
Сайт продолжит работать. Но для PHP 8.2 перестанут выходить исправления уязвимостей, и php.net рекомендует таким пользователям обновиться как можно скорее. Чем дольше сайт остаётся на неподдерживаемой версии, тем больше известных уязвимостей в ней накапливается.
Для WordPress и WooCommerce на ноябрь 2026 года практичный выбор — 8.3 или 8.4: WordPress рекомендует 8.3 и новее, WooCommerce протестирован до 8.4. Для Битрикса версию выбирайте вместе с подрядчиком после обновления ядра и модулей. Решающее слово за совместимостью ваших плагинов и модулей, а не за номером версии.
Версию PHP меняют не в WordPress, а на сервере: обычно в панели хостинга, в настройках сайта. Перед этим обновите WordPress, тему и плагины, сделайте резервную копию и проверьте магазин на копии с новой версией. После переключения проверьте «Здоровье сайта» и пройдите путь покупки.
После смены версии PHP главное — заметить, если заказы остановились, хотя сайт открывается. Pingvera для WooCommerce получает события заказов через WordPress-коннектор и поднимает алерт, когда поток заказов падает ниже почасовой нормы. Переключение PHP можно отметить как деплой: оно ляжет на один таймлайн с заказами и инцидентами, и связь будет видна сразу. Сквозная проверка форм подтвердит, что письма с сайта доходят до ящика. Бесплатный тариф покрывает до 5 сайтов с проверками раз в минуту.
Проверено: 11 ноября 2026 года
Pingvera следит за сайтами клиентов «снаружи и изнутри» — доступность из регионов, формы, оплата, домен, SSL, сервер — и предупреждает в Telegram, email и Max раньше, чем напишет клиент.
Попробовать Pingvera бесплатноЧитайте также: Обновление 1С-Битрикс: как обновить без поломки магазина · Чёрная пятница 2026: даты и план для интернет-магазина · Технический долг интернет-магазина · Экономика возвратов интернет-магазина · Бесплатно проверить сайт.