В феврале 2026 года Битрикс24 официально прекратил поддержку PHP версий ниже 8.2 для коробочных порталов. Примерно в то же время WordPress начал выводить предупреждения в разделе «Состояние сайта» о необходимости обновления PHP — даже для версий, которые ещё официально поддерживаются. Два самых популярных движка в российском вебе одновременно толкают разработчиков к переходу. И если вы ещё на PHP 8.0 или 8.1, пора считаться с тем, что откладывать дальше рискованно.
Давайте разберёмся по-честному: что реально меняется при переходе, где можно словить проблемы и как сделать апгрейд без простоев и нервов.
Что не так с PHP 7.4 и 8.0
PHP 7.4 перестал получать обновления безопасности в ноябре 2022 года. PHP 8.0 — в ноябре 2023-го. Это значит, что любые уязвимости, найденные после этих дат, исправлены не будут. Два года без патчей — для продакшн-сервера это уже не «потом обновим», а «работаем без страховки».
WordPress 6.7 формально ещё работает на PHP 7.4, но начиная с WordPress 6.5 команда начала активно рекомендовать PHP 8.1+, а в админке появились предупреждения. Практически все мажорные плагины — WooCommerce, Yoast SEO, Elementor — давно требуют минимум PHP 7.4, а их последние версии оптимизированы под 8.1 и 8.2.
С Битрикс24 всё жёстче: с 1 февраля 2026 поддержка PHP ниже 8.2 ограничена. Это значит, что новые обновления коробочной версии могут просто не работать на старом PHP. Без обновлений — без исправлений багов и уязвимостей. Замкнутый круг.
Что даёт PHP 8.2
Для веб-разработчика переход на 8.2 — это не просто «обновление ради обновления». Вот что реально меняется в повседневной работе:
Производительность. PHP 8.2 примерно на 20-25% быстрее PHP 7.4 в типичных веб-нагрузках. JIT-компилятор, который появился ещё в 8.0, к 8.2 заметно дозрел. Для сайта на WordPress с WooCommerce это может означать уменьшение времени ответа сервера на 50-100 мс. Не звучит впечатляюще, пока не вспомнишь, что Google считает каждый лишний 100 мс причиной снижения конверсии.
Типизация. Readonly-свойства, дискриминированные объединения (DNF-типы) и улучшенный вывод типов делают код надёжнее. Если вы пишете кастомные плагины или модули для Битрикс — это не косметика, а реальное снижение количества багов на проде.
Обработка строк. Функции mb_str_* теперь чувствительны к регистру по умолчанию. Это правильное решение, но оно сломает код, который полагался на старое поведение. Именно поэтому тестирование перед переходом — обязательно.
Депрекации. Классический пример: динамические свойства ($obj->undeclaredProp = value) вызывают deprecation warning в 8.2 и будут fatal error в 9.0. Плагины и темы, которые использовали этот паттерн, начнут сыпать предупреждениями в лог.
Где можно сломаться
Переход на PHP 8.2 не сложный, но есть несколько мест, где чаще всего возникают проблемы:
Старые плагины и темы WordPress. Если на сайте есть плагин, который не обновлялся два-три года — он почти гарантированно использует устаревшие API. Классический пример: плагин, который обращается к wpdb через прямые SQL-запросы с конкатенацией строк вместо $wpdb->prepare(). Это работало годами, но на 8.2 может упасть из-за изменений в обработке типов.
Кастомные решения для Битрикс24. Коробочный Битрикс имеет десятки файлов с кастомным кодом — обработчики событий, кастомные компоненты, интеграции с 1С. Если код писался под PHP 7.x, он почти наверняка использует removed или deprecated функции. Статический анализ через PHPCompatibility или Rector до перехода сэкономит часы отладки.
Серверное окружение. Некоторые хостинги до сих пор предлагают PHP 7.4 как версию по умолчанию. Перед переходом убедитесь, что хостинг поддерживает 8.2 в вашей тарифной панели. Если нет — это хороший повод задуматься о смене хостинга. Также проверьте, что все расширения PHP, которые использует ваш проект (mysqli, gd, xml, mbstring, zip, intl, opcache), доступны в 8.2.
Пошаговый план перехода
Вот рабочий план, который я использую при переводе клиентских сайтов на PHP 8.2:
Шаг 1. Аудит зависимостей. Соберите список всех активных плагинов и тем. Проверьте каждый в репозитории WordPress — есть ли версия, совместимая с PHP 8.2. Для платных плагинов проверьте changelog у разработчика. Для кастомного кода прогоните PHPCompatibility через Composer. Результат — список компонентов, которые нужно обновить или заменить.
Шаг 2. Статический анализ. Запустите phpcs –standard=PHPCompatibility или rector process на кастомном коде. Это автоматически найдёт большинство проблемных мест: deprecated функции, неявные nullable параметры, dynamic properties. Исправляете то, что нашли.
Шаг 3. Клонирование на стейджинг. Создайте полную копию сайта на тестовом окружении с PHP 8.2. Не на проде, не «на пару часов». Отдельный поддомен, отдельная база, чистая установка PHP 8.2.
Шаг 4. Тестирование. Пройдитесь по ключевым пользовательским сценариям: каталог товаров, корзина, оформление заказа, формы обратной связи, поиск, авторизация. Для Битрикс24 — обязательно проверьте интеграции: обмен с 1С, вебхуки, чат-боты, кастомные бизнес-процессы. Для WordPress — проверьте все шорткоды и кастомные блоки в Гутенберге.
Шаг 5. Переключение. Если всё работает на стейджинге — переключайте прод. Сделайте бэкап перед переключением. Имейте под рукой rollback-план: откатить PHP на старую версию и восстановить базу из бэкапа. На практике rollback почти никогда не нужен, если проделали шаги 1-4, но он должен быть.
Шаг 6. Мониторинг. Первые 48 часов после перехода — внимательно смотрите логи ошибок PHP. Даже если всё работает, могут появиться deprecation warnings, которые не вызывают видимых сбоев, но указывают на потенциальные проблемы в будущем.
Что делать, если что-то сломалось
Самая частая проблема при переходе — deprecated function. В PHP 8.2 их добавили несколько десятков. Вот самые популярные, с которыми я встречался:
utf8_encode()иutf8_decode()— удалены. Замена:mb_convert_encoding().get_magic_quotes_gpc()— удалена давно, но в legacy-коде всё ещё встречается.create_function()— замените на анонимные функции.- Динамические свойства —
$obj->propдля необъявленных свойств теперь deprecation. Объявите свойства в классе или используйте#[AllowDynamicProperties]как временную заплатку.
Для WordPress есть хелпер-плагины, которые временно подавляют deprecation warnings, чтобы дать время на исправление. Это нормально как промежуточный шаг, но не как постоянное решение — warnings есть не просто так.
WordPress 7.0 и дальнейшее
WordPress 7.0, выход которой запланирована на 2026 год, усилит требования к PHP. По данным Wordfence, в 2025 году было обнаружено 11 334 новых уязвимостей в экосистеме WordPress — рост на 42% по сравнению с 2024 годом. Из них 4124 относились к WordPress-плагинам. Часть этих уязвимостей связана именно с устаревшими версиями PHP, которые не получают патчи.
Словом, переход на PHP 8.2 — это не вопрос «когда будет время», а вопрос «сколько ещё можно рисковать». Для нового проекта — без вопросов, PHP 8.2+. Для действующего сайта — план перехода, описанный выше, занимает от пары часов до пары дней в зависимости от объёма кастомного кода. Это инвестиция, которая окупится стабильностью, скоростью и безопасностью.
Итого
PHP 8.2 — не новая мода, а базовое требование для безопасной и быстрой работы сайта в 2026 году. И WordPress, и Битрикс24 двигаются в этом направлении. Откладывать переход дальше — значит накапливать технический долг, который рано или поздно придётся оплачивать с процентами.
Если вы планируете переход и не уверены, с чего начать — напишите в комментариях, разберём вашу ситуацию. Если уже переходили — поделитесь опытом, что сломалось и как чинили.
