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

На проектах это обычно начинается спокойно.

Есть задача. Например, нужно поправить вывод цены, изменить поведение формы, добавить условие в компонент или быстро убрать ошибку после релиза. Разработчик находит подходящее место в системных файлах, меняет пару строк, проверяет страницу и видит, что все заработало.

В моменте решение кажется нормальным. Проблема в том, что сайт после такой правки уже перестает быть предсказуемым. Он выглядит как обычный проект на Битриксе, но часть проектной логики теперь спрятана внутри файлов платформы.

Ниже разберем, где проходит граница, почему такие правки потом дорого обходятся и как делать доработки без риска для обновлений.

Что считается ядром Битрикс

Под ядром мы имеем в виду файлы, которые поставляет и обновляет сама платформа. Их задача — обеспечивать работу системы, а не хранить особенности конкретного проекта.

Чаще всего ошибочно правят:

• файлы в /bitrix/modules/;
• стандартные компоненты в /bitrix/components/bitrix/;
• служебные файлы административной части;
• типовые шаблоны компонентов, которые забыли скопировать в проект;
• файлы модулей магазина, каталога, пользователей, поиска или обмена.

Если файл лежит внутри /bitrix и поставляется платформой, его нельзя считать местом для проектной логики. Даже если правка кажется маленькой.

Почему одна строка в ядре потом стоит дорого

Главная опасность не в самой строке кода. Опасность в том, что эта строка оказывается в месте, где ее никто не ожидает увидеть.

Например, кто-то поправил стандартный компонент или файл модуля:

if ($USER->IsAdmin()) {
    // временная логика, которая осталась навсегда
}

Через месяц сайт обновляют. Битрикс скачивает новую версию файла и заменяет старую. Платформа не знает, что внутри была проектная доработка. Для нее это просто системный файл, который нужно привести к актуальной версии.

Дальше начинается обычная история: форма снова работает не так, фильтр отдает другие товары, корзина ведет себя иначе, обмен с 1С падает на редком заказе. Связь с обновлением не всегда очевидна, потому что ошибка проявляется не в момент установки обновления, а позже — на конкретном сценарии.

Хуже всего, если правку делали без Git и без описания задачи. Тогда новый разработчик сначала выясняет не “как исправить проблему”, а “что здесь вообще стандартное, а что уже меняли руками”.

Что ломается из-за правок ядра

Последствия обычно накапливаются. Сайт может долго работать, но каждая следующая доработка становится осторожнее и дороже.

• Обновления становятся рискованными. Команда не понимает, какие системные файлы изменены и что пропадет после обновления.
• Исправления безопасности откладываются. Если обновляться страшно, сайт дольше живет на старой версии платформы и окружения.
• Диагностика занимает больше времени. Разработчик не может доверять стандартному поведению компонента или модуля.
• Новые специалисты медленнее входят в проект. Им приходится сравнивать файлы, искать нестандартные правки и восстанавливать историю решений.
• Переезд на новую версию PHP или Битрикса усложняется. Нестандартные изменения в ядре часто всплывают именно во время таких работ.

То есть правка ядра редко ломает сайт сразу. Она делает проект менее управляемым. И это почти всегда дороже, чем сразу вынести доработку в правильное место.

Как понять, что ядро уже правили

Если проект достался от другой команды или долго обслуживался без нормального контроля версий, сначала стоит проверить состояние ядра.

Мы обычно смотрим на несколько признаков:

• в проекте нет Git или в репозитории лежит только часть сайта;
• файлы внутри /bitrix/modules/ отличаются от чистой версии модуля;
• у системных файлов странные даты изменения;
• в стандартных компонентах встречаются комментарии вроде “временно”, “для клиента”, “быстрый фикс”;
• обновления Битрикса давно не ставились, потому что “после них что-то ломается”.

Отдельный тревожный сигнал — когда разработчики боятся нажимать кнопку обновления не из-за нагрузки или регламента, а потому что никто не знает, что именно изменено в системе.

Что делать вместо правки ядра

В большинстве случаев у Битрикса есть нормальный способ решить задачу без изменения системных файлов.

• Если нужно изменить верстку или порядок вывода, скопируйте шаблон компонента в /local/templates/ и работайте там.
• Если нужно подготовить данные перед шаблоном, используйте result_modifier.php или отдельный класс.
• Если нужно встроиться в процесс системы, посмотрите события Битрикса. Для многих задач это правильная точка расширения.
• Если стандартный компонент уже не подходит, лучше сделать свой компонент, чем переписывать стандартный.
• Если логика относится к бизнес-процессу сайта, вынесите ее в свой модуль или сервисный класс.

Например, шаблон стандартного компонента лучше дорабатывать не здесь:

/bitrix/components/bitrix/news.list/templates/.default/

А в проектной зоне:

/local/templates/site/components/bitrix/news.list/catalog/

Если ядро уже изменено

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

Нормальный порядок работы такой:

• найти все измененные системные файлы;
• понять, какую задачу решала каждая правка;
• перенести эту логику в шаблон, компонент, событие, класс или модуль;
• проверить сценарии, которые зависели от старой правки;
• вернуть системные файлы к штатному состоянию;
• после этого обновлять Битрикс уже на тестовой копии сайта.

Если правка нужна прямо сейчас как аварийная мера, ее все равно нужно оформить как временное решение: зафиксировать файл, причину, diff, задачу на перенос и срок, когда это будет убрано. Иначе временное станет постоянным.

Какой проект можно спокойно поддерживать

Хороший проект на Битриксе — не тот, где никогда нет сложных доработок. Сложные доработки бывают почти всегда.

Хороший проект — тот, где понятно, где живет код, кто его менял, зачем он нужен и как проверить результат после обновления.

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

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

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