Таки-таки всем привет. Мы много работаем с корпоративными порталами на Битрикс24 и регулярно сталкиваемся с убеждением: его кастомизировать нельзя. В народе ходит мнение, что это огромный коробочный монолит, любое вмешательство ломает обновления, и лучше туда вообще не лезть.

Откуда растут мифы

Причины этого предвзятого отношения во многом идут из прошлого. Наследие «Битрикс: Управление сайтом» до сих пор тянется за Б24: про ту систему говорили, что она медленная, тяжёлая и сложная в доработках. Плюс многие, кто когда-то пробовал кастомизировать портал «на коленке», сталкивались с проблемами и делали вывод, что «ничего хорошего из этого не выйдет». На деле же проблема была не в платформе, а в подходе.

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

Простые варианты

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

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

Когда нужно больше

Если простых инструментов мало, можно идти дальше и писать свои модули. Это уже почти без ограничений: хочешь — дописывай новый функционал, хочешь — меняй бизнес-логику. По сути это то же самое, что локальное приложение, только в более тесной интеграции с системой.

А если задача стоит глобальная — например, поменять внешний вид штатной оргструктуры или реализовать виртуальную очередь для блока маркетинга, чтобы почтовый сервер не захлёбывался, — тогда вариантов становится меньше.

Подход «в лоб»

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

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

Подход «изящный»

Другой способ — использовать bxjs. Это библиотека, через которую строится значительная часть пользовательских интерфейсов. Если точно понимаешь, что и где нужно поменять, можно написать свой JS и встроить его в нужное место.

Элегантность подхода в том, что мы не лезем в ядро вообще. При обновлениях ничего не ломается, а если кастомный JS вдруг перестал работать, почти всегда продолжает функционировать стандартный интерфейс. Портал остаётся живым, и пользователи не страдают. Минус в том, что если ядро меняет JS-логику, кастом придётся чинить. Но в этом методе как раз и есть красота: отвалился кастом — система всё равно работает.

Другие возможности

Есть ещё виджеты — например, в контакт-центре можно добавить свой блок. Можно работать через Bitrix24 UI Kit, использовать ui.buttons или даже встроить iFrame. В целом никто не мешает построить свой фронт на Vue или React, но это уже отдельная большая тема.

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

Итоги

Всё сводится к двум подходам: один быстрый и предсказуемый, но требующий поддержки после обновлений, другой — изящный и безопасный для ядра, но менее прогнозируемый. Любая кастомизация Б24 — это компромисс между скоростью, качеством и стабильностью. И задача разработчика — правильно выбрать баланс для