Один апдейт PHP может пройти тихо, а может выключить часть каталога, админку или интеграцию с 1С. В этой статье разбираем, какую версию PHP выбирать для 1С-Битрикс, что проверить до переключения и как пройти обновление без лишних сюрпризов.
История обычно начинается одинаково: вечером приходит уведомление от хостинга, и для Битрикс обновление PHP внезапно превращается в срочную задачу. Сайт вчера работал, сегодня ещё открывается, но в корзине уже странно ведут себя скидки, в админке всплывают предупреждения, а интеграция с внешним сервисом начинает отвечать дольше обычного. Самое неприятное здесь то, что проблема редко видна сразу. Она часто прячется в шаблоне, модуле, старом обработчике или в связке с библиотекой, которую никто не трогал годами.
С 1 февраля 2026 года в документации 1С-Битрикс минимальным требованием для продукта указана PHP 8.2.0, а рекомендуемой версией — 8.4 и выше. PHP.net при этом показывает, что ветка 8.2 уже находится только на security support, 8.3 остаётся поддерживаемой по безопасности до конца 2027 года, а 8.4 — до конца 2028 года. То есть выбор версии PHP для Битрикс сегодня уже не про «что-нибудь посвежее», а про нормальный жизненный цикл и запас по поддержке.
Ниже разберу это без лишней теории: с чего начать, где обычно спотыкаются проекты на 1С-Битрикс и как действовать, если менять PHP нужно уже сейчас.
Битрикс обновление PHP: почему ошибка всплывает не сразу
У многих админов есть опасная иллюзия: если сайт открылся после переключения, значит всё в порядке. На практике PHP может пропустить первый экран, но споткнуться на отдельной функции позже. Например, каталог работает, а оформление заказа падает только на конкретном шаге. Или публичная часть выглядит нормально, но в фоновых задачах ломается обмен, импорт, почта или автопересчёт данных.
Причина проста: в Битриксе почти всегда есть смесь кода разного возраста. Есть ядро, есть решения из Маркетплейса, есть кастомные компоненты, а сверху ещё интеграции с 1С, CRM, оплатой и доставкой. Один и тот же апдейт PHP может пройти без шума на одном проекте и вызвать цепочку ошибок на другом, если там остались старые вызовы функций, неаккуратная работа с типами или библиотека, которая давно не обновлялась.
PHP-мания на практике часто выглядит так: разработчик меняет версию, видит один warning, исправляет его и считает задачу закрытой. Но PHP 8.x строже относится к тому, что раньше «как-то терпел». Поэтому полезно проверять не только главную страницу, а весь типовой маршрут пользователя: каталог, карточку товара, корзину, оформление заказа, личный кабинет, формы, поиск и обмены. Если в этих местах всё спокойно, уже можно считать апдейт удачным шагом, а не удачной случайностью.
Что проверить в первую очередь
Если у вас нет времени на длинную диагностику, начните с трёх вещей. Первая — версия PHP на проде и на тестовой копии. Вторая — список включённых модулей и расширений. Третья — самые посещаемые сценарии: заказ, авторизация, выгрузка, импорт и фоновые агенты.
Такой подход экономит часы. Он не пытается угадать всё сразу, а быстро показывает, где проект уязвим. Именно там и стоит искать проблему в первую очередь.
Требования PHP Битрикс: что проверить до переключения
Когда речь идёт про требования php битрикс, я советую начинать не с версии PHP как таковой, а с окружения в целом. Документация Битрикс прямо указывает на минимальную версию PHP и рекомендуемую ветку, но на реальном проекте важны ещё и расширения, база данных, веб-сервер, cron и состав подключённых решений. Если один из этих слоёв слабый, апдейт PHP только усилит слабое место.
Перед переключением сделайте короткий аудит. Не на словах, а по списку. Это уже снижает риск сильнее, чем «надеюсь, всё заведётся». Для большинства магазинов на 1С-Битрикс этого достаточно, чтобы поймать 80% проблем ещё до смены версии.
| Что проверить | Что сделать прямо сейчас |
|---|---|
| Текущая версия PHP | Сверить прод, стейдж и локальную копию |
| Расширения PHP | Проверить GD, mbstring, intl, XML, ZIP и поддержку БД |
| Сторонние модули | Обновить решения из Маркетплейса до актуальных версий |
| Кастомный код | Прогнать поиск по устаревшим вызовам и нестандартным обработчикам |
| Фоновые задачи | Проверить cron, агенты, импорт и почтовые очереди |
Три действия, которые можно сделать сразу:
- снять бэкап файлов и базы перед любым изменением;
- поднять копию сайта на тестовом сервере и переключить PHP там;
- собрать список всех нестандартных модулей, шаблонов и интеграций.
PHP сам по себе тоже эволюционирует не без последствий. В официальной документации PHP для каждой новой ветки отдельно указаны миграционные заметки и несовместимости, которые нужно тестировать перед переходом в продакшен. Это прямой сигнал: даже «минорный» апдейт в рамках новой ветки может поменять поведение кода.
Поэтому главный критерий готовности не «сервер отвечает», а «все критические сценарии отрабатывают одинаково на старой и новой версии». Если это не проверено, обновление пока не завершено.
Совместимость PHP Битрикс: где чаще всего ломается
Тема совместимость PHP и Битрикс почти всегда упирается в код, который писали под прошлую логику PHP. Это не обязательно плохой код. Просто он мог долго работать в более мягком режиме. После перехода на новую ветку PHP ошибки часто всплывают в местах, где раньше были только предупреждения или скрытые допущения.
Первое слабое место — самописные компоненты и обработчики событий. Особенно те, что меняли данные «на лету», полагались на нестрогие типы или возвращали неполные структуры. Второе — старые решения из Маркетплейса. Третье — внешние библиотеки, которые подтягиваются через composer или лежат в проекте отдельной папкой. Именно здесь обновление PHP 8 Битрикс чаще всего требует ручной проверки, а не автоматической надежды.
Что обычно ломается быстрее других
На практике я бы первым делом смотрел на вызовы, которые завязаны на массивы, строки и null-значения. Дальше — на старые шаблоны с неаккуратными проверками условий. Затем — на обмен с 1С, вебхуки, почтовые обработчики и длинные цепочки кастомных функций. Если в проекте есть inherited-логика, скрытые переопределения классов или собственные версии библиотек, они тоже заслуживают отдельного внимания.
Ещё одна зона риска — интеграции. Магазин может работать сам по себе, а падать только в момент отправки заказа в CRM. Или всё выглядит нормально, пока не включается ночной обмен. Именно поэтому простая ручная проверка пары страниц здесь не спасает. Нужен сценарий, похожий на реальную нагрузку.
Если нужен ориентир, думайте не «сломается ли сайт», а «какая часть бизнес-процесса станет первой жертвой». Чаще всего это не главная страница, а то место, где данные меняют формат, переходят в очередь или уходят во внешнюю систему.
PHP 8 Битрикс: что меняется после апдейта
Когда проект переходит на PHP 8 Битрикс, меняется не только версия интерпретатора. Меняется сам тон общения системы с кодом. Там, где PHP 7.x был терпеливее, PHP 8.x чаще выбирает более строгую реакцию. Это полезно для качества, но неприятно для старых проектов, особенно если их долго не трогали. В официальных заметках PHP прямо сказано, что новые ветки содержат несовместимости, которые нужно тестировать до запуска в продакшене.
Что это значит для владельца сайта? Сначала появляются предупреждения, потом — точки падения в отдельных сценариях. Иногда достаточно одной функции, одного устаревшего класса или одной сторонней библиотеки, чтобы оформление заказа начало вести себя иначе. Поэтому на PHP 8 лучше сразу смотреть на весь стек: ядро, шаблоны, API, cron, обмены, платёжные модули и сторонние решения.
Чек-лист для PHP 8
Если вы уже перешли или только планируете переход, проверьте следующие вещи:
- нет ли предупреждений и TypeError в логах;
- работает ли авторизация, восстановление пароля и регистрация;
- проходит ли заказ до конца без скрытых сбоев;
- отрабатывают ли агенты и cron-задачи по расписанию;
- не ломается ли обмен с 1С и внешними сервисами;
- совпадает ли поведение тестовой и боевой копии.
С точки зрения поддержки тоже важно держаться актуальной ветки. Сейчас PHP 8.3 и 8.4 уже полностью вписаны в современный цикл поддержки, а 8.2 движется к завершению security support. Для новых серверов это означает простую вещь: ставить старую ветку ради спокойствия уже не получается. Спокойнее как раз та версия, которую ещё будут сопровождать достаточно долго.
Если у вас старый проект, переход лучше делать ступеньками: сначала поднять совместимость кода, потом проверить расширения, потом переключить PHP на тесте, и только после этого включать прод. Такой маршрут почти всегда дешевле, чем разбор уже упавшего магазина ночью.
Версия PHP для Битрикс: как выбрать без лишнего риска
Если смотреть прагматично, версия PHP для Битрикс выбирается не по принципу «самая новая», а по принципу «самая безопасная для моего стека». Для свежего проекта с актуальными модулями и нормальной поддержкой кода логично смотреть на 8.4. Для проекта, где есть несколько сторонних решений и не всё обновлялось вовремя, разумнее сначала пройти через 8.2 или 8.3 на тестовой копии и только потом повышать планку. Документация 1С-Битрикс уже держит минимальную планку на 8.2, а рекомендует 8.4+, так что ориентир здесь достаточно ясный.
Я бы выбрал схему без героизма. Сначала зафиксировать текущую версию и собрать список зависимостей. Потом обновить модули и решения. Затем прогнать сайт на копии под целевой версией PHP. И только после этого переносить изменения на прод. Такой порядок не выглядит эффектно, зато даёт предсказуемый результат.
Есть и простой практический критерий. Если после теста у вас не осталось неожиданных warnings, не сломались формы, корректно отрабатывают cron и обмены, а логи чистые — версия выбрана верно. Если же приходится править код уже после переключения, значит, решение принималось слишком рано.
Три шага, которые стоит сделать сегодня:
- проверить, какая версия PHP стоит на проде и на тесте;
- обновить Битрикс и сторонние решения до актуальных релизов;
- сделать тестовый прогон ключевых сценариев на копии сайта.
Если у вас магазин, который уже живёт на PHP 7.x или раннем 8.x и при этом давно не проходил ревизию, не откладывайте аудит. Чем позже вы его начнёте, тем больше будет цена каждой следующей ошибки. Гораздо спокойнее проверить сервер заранее и перевести проект на актуальную ветку без спешки. Если нужен безопасный маршрут, проверьте сервер на support.orangecode.ru.