PHP 8.2 — конец поддержки: что делать с сайтом на WordPress

Хостинг прислал письмо о смене версий PHP, в админке WordPress висит жёлтое уведомление «обновите PHP», а подрядчик говорит: «всё работает, не трогайте». Причина общая: PHP 8.1 без поддержки с 1 января 2026 года, у PHP 8.2 конец поддержки наступает 31 декабря 2026-го, а вслед за языком поднимают требования WordPress и WooCommerce. В статье: чем это грозит сайту, как за две минуты узнать свою версию PHP и в каком порядке переходить на PHP 8.3, чтобы сайт не упал.

Что значит «PHP без поддержки»

PHP — язык, на котором написаны WordPress и большинство других систем управления сайтом. Код сайта выполняет интерпретатор PHP на сервере хостинга, и у каждой его версии ограниченный срок службы. Около двух лет после выхода идёт активная поддержка: разработчики исправляют ошибки и уязвимости и регулярно выпускают обновления. Ещё два года версия получает только исправления безопасности, причём лишь критичные и по мере необходимости. Потом наступает конец жизни (end of life): обновлений нет, php.net советует переходить на новую версию как можно скорее.

Календарь на 8 ноября 2026 года по официальной странице поддерживаемых версий PHP:

В PHP 8.2 обычные ошибки не исправляют уже почти два года, а с 1 января 2027-го перестанут закрывать и уязвимости. Ветка 8.1 закрыта: последний выпуск — 8.1.34, новых не будет. Разница видна на примере октября 2026 года: PHP выпустил 8.2.35, 8.3.36, 8.4.27 и 8.5.12 с исправлениями безопасности, а ветка 8.1 ничего не получила (подробнее — в статье PHP2Shell: критические уязвимости PHP).

По статистике wordpress.org на 8 ноября 2026 года около 32 % установок WordPress, которые отправляют туда данные, работают на PHP ниже 8.2, ещё почти 23 % — на PHP 8.2. Без обновления к январю больше половины таких установок окажутся на PHP без поддержки.

Чем грозит старый PHP

1 января 2027 года сайт на PHP 8.2 не выключится: он будет открываться и принимать заказы, как раньше. Проблемы накапливаются постепенно.

Уязвимости остаются открытыми. Если после 31 декабря в PHP 8.2 найдут уязвимость, исправления для этой ветки не выйдет. CMS и плагины могут быть обновлены до последних версий, но под ними останется язык, в котором новые уязвимости никто не закроет.

CMS перестают обновляться на старом PHP. Это уже происходит:

• WordPress 7.0 (май 2026) поднял минимальную версию PHP до 7.4. Сайты на PHP 7.2 и 7.3 остались на ветке 6.9 и новых версий ядра не получат.
• WooCommerce 11.6, запланированный на февраль 2027 года, потребует PHP 8.1 или новее. Последний выпуск для PHP 7.4 и 8.0 — 11.5; в него будут переносить только исправления уязвимостей с оценкой CVSS 9 и выше.

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

Старый PHP начинает стоить денег. Хостинги не держат устаревшие версии вечно: версию могут убрать из панели или сделать платной. GoDaddy с 1 января 2026 года перевёл PHP 8.1 в платную надстройку «расширенная поддержка» и подключает её автоматически при продлении тарифа: владелец платит за то, что сайт остаётся на устаревшей версии.

Как узнать версию PHP на своём сайте

Для проверки программист не нужен.

WordPress. Откройте «Инструменты → Здоровье сайта», вкладку «Информация», раздел «Сервер». В строке «Версия PHP» указана текущая версия; если там 8.3 или выше, срочных действий не нужно. Магазины на WooCommerce с PHP 7.4 или 8.0 начиная с WooCommerce 11.3 видят в админке отдельное уведомление с версией PHP; версия есть и в разделе «WooCommerce → Статус», блок «Серверное окружение».

Любой другой движок. В cPanel, Plesk, ISPmanager и панелях украинских хостингов есть раздел выбора версии PHP. Там видно, какая версия включена для каждого сайта и какие доступны.

Фоновые задачи (cron) — выгрузка товаров, обмен с учётной системой, рассылки — иногда работают на другой версии PHP, чем сайт: сайт уже на 8.3, а ночной импорт прайса идёт на 7.4. Если такие задачи есть, попросите хостинг или администратора сервера проверить версию и для них.

Почему нельзя просто переключить версию в панели

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

• В PHP 8.0 удалены функции create_function() и each(), частые в темах и плагинах десятилетней давности. На PHP 8 вызов такой функции даёт фатальную ошибку, и страница не открывается.
• В PHP 8.0 запрещён статический вызов обычного метода класса. Это одна из самых частых ошибок после перехода: в журнале появляется «Non-static method … cannot be called statically».
• В PHP 8.2 объявлено устаревшим создание динамических свойств объекта. Сайт работает, но журнал заполняется уведомлениями Deprecated. В следующих версиях PHP такой код может перестать работать, поэтому исправить его лучше заранее.

Ядро WordPress на новых версиях PHP проверяют сами разработчики. Ломается обычно то, что добавлено к ядру:

1. Тема или шаблон на заказ, написанные много лет назад и с тех пор не обновлявшиеся.
2. Заброшенные плагины и модули, в том числе «нулёные» (взломанные) копии платных плагинов: они не обновляются вовсе.
3. Свой код: правки в файлах темы, интеграции с учётной системой и службами доставки, скрипты импорта.

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

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

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

Порядок безопасного перехода на PHP 8.3

Последовательность подходит для любого сайта на PHP; особенности WordPress и WooCommerce — в следующем разделе.

Какая версия PHP нужна. WordPress рекомендует PHP 8.3 или выше. Мы советуем 8.3 как минимум, а 8.4 — если все плагины или модули сайта официально её поддерживают: исправления безопасности для 8.4 будут выходить до конца 2028 года, для 8.3 — до конца 2027-го. Переходить на 8.2 сейчас бессмысленно: через два месяца работу придётся повторять. У 8.4 есть особенность: расширение IMAP (через него сайт забирает почту из ящика) убрано из стандартной поставки PHP, и на хостинге его может не быть.

1. Составьте опись. Версия CMS, плагины или модули, тема или шаблон, лицензии на платные расширения, интеграции и фоновые задачи. Часто на этом шаге выясняется, что часть плагинов не обновлялась годами. В разделе выбора версии PHP в панели хостинга сравните расширения PHP: какие включены сейчас и есть ли они у новой версии. Если у новой версии нет, например, soap или gd, при исправном коде сайта перестанут работать обмен с внешним сервисом или обработка картинок.
2. Сделайте резервную копию файлов и базы данных и проверьте, что сайт из неё восстанавливается. Бывает, что в архиве нет базы или он повреждён, и выясняется это в день аварии.
3. Разверните тестовую копию на отдельном домене (например, test.вашсайт.com) с теми же версиями PHP, базы данных и веб-сервера, что на рабочем сервере. Закройте копию паролем от посетителей и поисковых роботов, отключите на ней реальные платежи, письма клиентам и обмен с учётной системой, иначе тестовые заказы дойдут до бухгалтера.
4. Обновите CMS, плагины и модули ещё на старой версии PHP. Многие ошибки после перехода уже исправлены в свежих версиях плагинов и ядра.
5. Переключите PHP на тестовой копии и включите журнал ошибок. Пройдите сайт глазами клиента и сотрудника: главная, каталог, фильтр, карточка товара, корзина, оформление заказа, оплата в тестовом режиме, формы, личный кабинет, поиск, админка. Отдельно запустите импорт, выгрузки и другие фоновые задачи.
6. Исправьте найденное. Несовместимый плагин обновляют или меняют на аналог, старый код темы переписывают. Если замены плагину нет, а автор не отвечает, нужен разработчик.
7. Переключите рабочий сайт в часы наименьшей нагрузки, сразу после свежей резервной копии. Сбросьте кеш CMS и плагина кеширования, иначе посетители и вы будете видеть страницы, собранные ещё старой версией PHP, и проверка покажет неверную картину. Затем пройдите те же сценарии, что на тестовой копии.
8. Наблюдайте несколько дней. Часть ошибок проявляется только на редких действиях: возврат заказа, ночной cron, выгрузка в маркетплейс раз в сутки. Журнал ошибок просматривайте ежедневно.

План отката

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

Базу из резервной копии восстанавливают только в крайнем случае: всё, что произошло после создания копии (заказы, регистрации, заявки), пропадёт. Для интернет-магазина это потерянные заказы, поэтому их заранее выгружают или переключают сайт в окно, когда заказов почти нет.

Особенности WordPress и WooCommerce

Для обновления PHP на WordPress есть официальная инструкция wordpress.org. Она советует обновить ядро, темы и плагины, а совместимость проверить плагином PHP Compatibility Checker. С последним советом мы не согласны. Плагин на своей странице в каталоге предупреждает: он больше не поддерживается, новых версий, включая исправления безопасности, не будет, а проверяет он совместимость только до PHP 8.0. Для перехода на 8.3 его результат почти бесполезен; надёжнее проверка на тестовой копии с включённым журналом ошибок.

Если в теме и плагинах много своего кода, программист может дополнительно прогнать его через набор правил PHPCompatibilityWP для PHP_CodeSniffer (программа анализирует код без запуска сайта), указав целевую версию 8.3. Такая проверка находит удалённые и устаревшие функции, но поведение сайта с реальными данными не покажет, поэтому тестовую копию не заменяет.

Журнал ошибок в WordPress включают в файле wp-config.php на тестовой копии:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Ошибки пишутся в файл wp-content/debug.log, посетители их не видят. На рабочем сайте отладочный режим не держат: документация WordPress называет эти инструменты средством для локальной и тестовой среды, так что после проверки выключите его.

Что ещё проверить на WordPress:

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

Если после переключения вместо сайта появилось сообщение «На сайте возникла критическая ошибка», порядок действий описан в статье критическая ошибка WordPress после обновления.

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

Можно ли остаться на PHP 8.2 после 31 декабря 2026 года?

Сайт продолжит открываться, но новые уязвимости в PHP 8.2 закрывать не будут, а хостинг может убрать 8.2 из панели или сделать платной. WordPress рекомендует PHP 8.3 или выше; переход лучше спланировать самому и не ждать письма от хостинга.

Стоит ли переходить сразу на PHP 8.5?

PHP 8.5 — самая новая выпущенная версия: активная поддержка до конца 2027 года, исправления безопасности до конца 2029-го. Правило то же, что для 8.4: переходить, только если CMS, тема и все плагины или модули официально поддерживают эту версию. Если хотя бы один важный плагин её не поддерживает, остановитесь на 8.3 или 8.4.

Сайт старый, подрядчика нет: с чего начать?

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

• Соберите доступы. Панель хостинга, FTP или SSH, база данных, админка сайта, регистратор домена. Для платных плагинов WordPress — аккаунты, где они куплены.
• Убедитесь, что хостинг и домен оформлены на вас, а не на бывшего подрядчика. Если на него, переоформите до начала работ: как это сделать, описано в статье разработчик пропал: как забрать сайт.
• Сделайте резервную копию через панель хостинга и скачайте её к себе.
• Запишите, что на сайте должно работать: формы, заказы, интеграции, выгрузки. По этому списку новый подрядчик проверит сайт после перехода.

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

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

Как с переходом на новый PHP помогает RIVERIT

Предлагаем взять сайт на техническую поддержку: в неё входят обновления CMS и плагинов (обычно ежемесячно), резервные копии и мониторинг сайта и домена. Переход на новую версию PHP проводим по порядку из этой статьи: тестовая копия, проверка, исправление кода, переключение и наблюдение после него; работаем с сайтами на WordPress и WooCommerce, а также на Laravel и Django. Если сайт стоит на VPS или выделенном сервере, берём сервер на администрирование (сервер арендуется на ваш аккаунт), включая смену версии PHP. Если текущий хостинг не поддерживает PHP 8.3, перенесём сайт на наш хостинг: серверы в Европе, ежедневные резервные копии в отдельное хранилище, перенос с другого хостинга входит в техподдержку. Клиентам на поддержке отвечаем в течение часа, а если сайт упал, чиним и в нерабочее время, если это входит в тариф.