Как включить расширенный вывод ошибок PHP в settings.php на 1С-Битрикс: отладка без утечки на проде

Сайт на 1С-Битрикс вместо понятной ошибки показывает заглушку "При выполнении скрипта возникла ошибка" и намекает на файл настроек - но не говорит, какой именно и что менять. Вы ставите debug в true, а экран остается пустым или на бою случайно светит пути к файлам посетителям. Ниже - как включить расширенный вывод PHP-ошибок через блок exception_handling в .settings.php, настроить лог на production и вернуть debug в false после отладки.

Расширенный вывод включают в exception_handling файла /bitrix/.settings.php (или /local/ с main 24.100.0) — debug с false на true. Если тишина, проверьте .settings_extra.php. На бою debug = false, ошибки в log.file (bitrix/modules/error.log). Перед правкой — бэкап: синтаксическая ошибка «уронит» сайт.

Речь про CMS «1С-Битрикс: Управление сайтом», не Bitrix24. Ловушка: ищут settings.php без точки. Нужен .settings.php; dbconn.php с 20.900.0 для БД не используется.

Определите, когда включать вывод на экран, а когда смотреть логи

Расширенный вывод на экран — на dev/stage, когда правите шаблон или интеграцию. На production стек посетителям нельзя: в ошибке видны пути, версии модулей и SQL.

Делайте: разделяйте dev и prod - на копии включайте экран, на бою только лог. Не делайте: не оставляйте debug = true "на ночь" после хотфикса - это типичная утечка после интеграции с 1С.

Найдите правильный файл: .settings.php, а не settings.php

Конфигурация D7 лежит в .settings.php: /bitrix/.settings.php или с версии 24.100.0 (2026) в /local/.settings.php.

Файл /bitrix/.settings_extra.php сливается с основным и часто возвращает debug в false на production. На практике типичная ошибка: debug=true в .settings.php, а в extra для всех IP кроме офиса — false, страница обмена с 1С белая. В реальном проекте часто ещё log.file = NULL и пустой perfmon. Открывайте оба файла через FTP или «Структура сайта — bitrix».

Делайте: ищите .settings.php с точкой. Не делайте: не путайте с dbconn.php. В гайде по почте та же секция smtp, не exception_handling.

Разберите блок exception_handling: debug, типы ошибок и log

В .settings.php найдите exception_handling → value. Ключ debug — экран (true на dev) или заглушка (false на бою). log.file — куда писать (по умолчанию bitrix/modules/error.log). ini_set в init.php не заменит эту секцию.

'exception_handling' => array(
  'value' => array(
    'debug' => true,
    'log' => array(
      'settings' => array(
        'file' => 'bitrix/modules/error.log',
        'log_size' => 1000000,
      ),
    ),
  ),
),

На BitrixVM log.file может быть абсолютным (/var/log/php/) — в админке не виден, нужен SSH.

Делайте: меняйте только value в exception_handling. Не делайте: не ставьте log.file в NULL на production.

Включите debug на dev или stage: пошагово

Workflow для безопасной отладки: бэкап → правка → проверка стека → откат. Четыре шага:

1. Скопируйте /bitrix/.settings.php (и при наличии .settings_extra.php) в безопасное место или сделайте снимок через панель хостинга.
2. Откройте .settings.php, найдите exception_handling → value → debug и замените false на true. Сохраните в UTF-8 без BOM — синтаксическая ошибка даст HTTP 500 на весь сайт.
3. Обновите проблемную страницу в браузере. Ожидаемый результат — текст ошибки с Class not found, файлом, строкой и цепочкой #0, #1.
4. Если снова заглушка или пустой экран — откройте .settings_extra.php и поищите там debug = false или условие по IP.

Схема диагностики:
Заглушка на экране → правка debug в .settings.php → нет эффекта → проверка .settings_extra.php → всё ещё тишина → php.ini и логи nginx/php-fpm

Делайте: отладку на копии. Не делайте: не правьте .settings.php на production без окна обслуживания.

Настройте логирование на production без показа стека

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

'debug' => false,
'log' => array(
  'settings' => array(
    'file' => 'bitrix/modules/error.log',
    'log_size' => 1000000,
  ),
),

Без SSH включите «Вести журнал предупреждений PHP» в perfmon (Настройки — Производительность — Ошибки PHP). Про хостинг — в материале про сервер для Битрикс; для VPS — Beget.

Делайте: скачивайте error.log в тикет. Не делайте: не публикуйте лог с путями без редактирования.

Устраните типичные сбои: debug true, а ошибки не видны

• Заглушка не исчезла - override в .settings_extra.php.
• Белый экран - fatal до prolog: логи nginx, php-fpm, на VM /var/log/php/.
• Обмен с 1С - откройте URL в браузере с debug или смотрите лог cron-агента.

Делайте: после правки — инкогнито. Не делайте: не ставьте ini_set вместо exception_handling.

Пройдите чек-лист отката после отладки

1. debug = false в .settings.php и .settings_extra.php.
2. Diff с бэкапом: лишних правок в connections и smtp нет; главная и проблемная страница без стека на экране.
3. log.file не NULL, error.log пишется на копии.
4. Отметьте пункт «debug выключен» в чек-листе после запуска или регламенте поддержки.

Делайте: храните бэкап. Не делайте: не коммитьте debug = true.

Что дальше

Если заглушка осталась, соберите скрин, фрагмент exception_handling (без паролей) и хвост error.log — разбор займёт меньше часа. Для сопровождения — напишите нам.

Автор: Максим Мольков, разработчик 1С-Битрикс.
Источники: документация D7 по конфигурации ядра, учебный курс по параметрам ядра, API ExceptionHandler.

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