init.php в Битрикс: что это и как правильно использовать

init.php — файл, который 1С-Битрикс подключает при каждом обращении к сайту, до того как начнёт формироваться страница. Всё, что в нём объявлено, доступно и в публичной части, и в административной, и в компонентах.

Это стандартное место для обработчиков событий, вспомогательных функций и констант проекта. Разберём, где файл должен лежать, что в него стоит класть, а что нет, и почему разросшийся init.php со временем начинает тормозить сайт.

Где лежит файл

Битрикс ищет init.php в двух местах:

Путь	Комментарий
`/local/php_interface/init.php`	Правильное место. Не затирается при обновлении ядра
`/bitrix/php_interface/init.php`	Устаревший вариант, остался в старых проектах

Важная деталь: подключаются оба файла, если существуют. Сначала /bitrix/php_interface/init.php, затем /local/php_interface/init.php.

Это регулярно становится источником путаницы: разработчик правит файл в /local/, а обработчик из /bitrix/ продолжает работать и делать своё. При разборе чужого проекта проверяйте оба пути.

Когда именно он подключается

Порядок загрузки такой:

Подключается пролог /bitrix/modules/main/include/prolog_before.php;
инициализируется ядро, база данных, сессия;
подключается init.php;
определяется текущий шаблон;
формируется страница.

Ключевой момент: на этапе init.php ядро уже доступно — можно обращаться к базе, к $USER, к настройкам. Но страница ещё не начала формироваться, поэтому здесь можно перехватывать события до вывода.

Нужна помощь с Битрикс?

Что класть в init.php

Обработчики событий

Основное назначение файла. Именно отсюда навешиваются перехватчики событий ядра:

<?php

AddEventHandler('main', 'OnBeforeUserAdd', 'checkUserEmail');

function checkUserEmail(&$arFields)
{
    if (empty($arFields['EMAIL'])) {
        global $APPLICATION;
        $APPLICATION->throwException('Не указан e-mail');
        return false;
    }

    return true;
}

Для нового кода предпочтительнее EventManager из D7 — он разобран в отдельной статье EventManager в Битрикс.

Константы проекта

<?php

define('IBLOCK_NEWS',    5);
define('IBLOCK_CATALOG', 12);
define('COMPANY_PHONE',  '+7 (495) 000-00-00');

Идентификаторы инфоблоков в константах — распространённая практика. Она избавляет от магических чисел в коде и упрощает перенос проекта: при развёртывании на другом сервере ID меняются в одном месте.

Автозагрузка своих классов

Складывать все функции в один файл неудобно. Правильнее вынести код в классы и подключить автозагрузчик:

<?php

use Bitrix\Main\Loader;

Loader::registerAutoLoadClasses(null, [
    'Project\\Helper\\Catalog' => '/local/php_interface/classes/Helper/Catalog.php',
    'Project\\Helper\\User'    => '/local/php_interface/classes/Helper/User.php',
]);

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

Подключение composer

Если в проекте используются сторонние библиотеки:

<?php

if (file_exists(__DIR__ . '/../vendor/autoload.php')) {
    require_once __DIR__ . '/../vendor/autoload.php';
}

Проверка существования файла обязательна: без неё сайт упадёт с фатальной ошибкой на сервере, где зависимости ещё не установлены.

Чего в init.php быть не должно

Файл выполняется на каждом хите — включая AJAX-запросы, обращения к административной части и служебные вызовы. Всё, что здесь происходит, происходит постоянно.

Запросы к базе данных. Выборка инфоблока «чтобы было под рукой» добавляет запрос к каждому обращению к сайту, даже туда, где эти данные не нужны.
Обращения к внешним API. Сторонний сервис тормозит — тормозит весь сайт целиком.
Вывод чего бы то ни было. Любой echo или даже лишний перевод строки после закрывающего ?> приводит к ошибке «headers already sent».
Тяжёлые вычисления. Им место в компоненте с кешированием.
Бизнес-логика страниц. Логика конкретной страницы должна жить на странице или в компоненте.

Про ошибку с выводом до заголовков есть отдельный разбор — Ошибка Headers Already Sent в Битрикс. Лишний пробел в конце init.php — одна из самых частых её причин.

Как не превратить файл в свалку

Через год работы проекта init.php обычно разрастается до нескольких сотен строк, в которых перемешаны обработчики, функции и константы. Разобраться в этом становится невозможно.

Рабочая структура — разбить файл на части и подключать их:

<?php // /local/php_interface/init.php

$includes = [
    'constants.php',   // константы проекта
    'autoload.php',    // регистрация классов
    'events.php',      // обработчики событий
    'helpers.php',     // вспомогательные функции
];

foreach ($includes as $file) {
    $path = __DIR__ . '/include/' . $file;

    if (file_exists($path)) {
        require_once $path;
    }
}

Сам init.php остаётся коротким и понятным, а искать нужный обработчик становится проще.

Отладка

Если код в init.php не срабатывает, проверяйте по порядку:

Тот ли файл вы правите. Проверьте оба пути — в /local/ и в /bitrix/.
Нет ли синтаксической ошибки. При ошибке в init.php падает весь сайт, включая админку. Проверить можно командой php -l init.php.
Правильно ли назван обработчик. Опечатка в имени события не вызывает ошибки — обработчик просто молча не срабатывает.
Не кеширован ли результат. Если обработчик влияет на вывод компонента, закешированная страница покажет старые данные.

Для проверки, что файл вообще подключается, удобно писать в лог, а не выводить на экран:

<?php

\Bitrix\Main\Diag\Debug::writeToFile(
    'init.php подключен',
    'DEBUG',
    '/local/logs/debug.log'
);

Итог

init.php в папке /local/php_interface/ — точка входа для кода проекта: обработчиков событий, констант и регистрации автозагрузки классов. Подключается на каждом хите после инициализации ядра, но до формирования страницы.

Два правила определяют, останется ли проект поддерживаемым: не выполнять здесь запросы к базе и обращения к внешним сервисам, и разбивать файл на смысловые части вместо того, чтобы дописывать всё в конец.