Основой БУС и главным строительным материалом системы являются компоненты. Для тех, кто не в курсе, это такая сущность, которая объединяет в себе всё необходимое для работы какого-то функционального блока на сайте. Это может быть баннер, или список «новинок», слайдер с брендами вашего магазина, целая страница каталога или даже полноценный раздел типа «Блог». Возможности компонентов, по большому счету, не ограничены, и с помощью них можно решать разнообразные задачи - от вывода телефона в шапке и заканчивая разработкой REST API из пятиста точек входа.

Довольно часто разработчики используют стандартные компоненты, которые идут в поставке вместе с БУС. Документацией определен механизм расширения компонентов - в зависимости от способа реализации базового компонента вы либо создаете дополнительный шаблон для него, либо копируете компонент целиком, либо наследуетесь от него, если он был разработан с помощью ООП подхода.

Но бывают ситуации, когда этих возможностей не хватает. Например, компоненты БУС могут использоваться самим ядром системы, админкой. Чтобы кастомизировать компонент в админке, вам потребуется отредактировать ядро, что является очень плохой идеей. Но есть другой выход!

Битрикс имеет долгую историю развития компонентов. Сначала все компоненты лежали в директории /bitrix - я говорю не только о компонентах ядра, но и о компонентах разработчиков. Потом появилась директория /local, куда переехали компоненты разработчиков. В связи с этим несколько изменился алгоритм подключения компонентов. Он довольно прост и выглядит следующим образом:

  • сначала на основании имени компонента формируется «относительный путь». Это производится в методе \CComponentEngine::makeComponentPath
  • после к нему приклеивается DOCUMENT_ROOT и /local/components или /bitrix/components, в зависимости от того, что будет найдено первым

И вот оно что получается. Допустим, мы подключаем компонент bitrix:news.list

$APPLICATION->IncludeComponent('bitrix:news.list', '.default', []);

В соответствии с описанным алгоритмом можно создать директорию /local/components/bitrix/news.list, и битрикс полезет туда в первую очередь 🙂

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

Как использовать?

Обмен с 1С

По-умолчанию процесс обмена данными между 1С и сайтом происходит с помощью точки входа /bitrix/admin/1c_exchange.php. В этом скрипте подключаются встроенные битриксовые компоненты. Теперь, если вдруг критически важно иметь именно стандартный путь для точки входа, то вы можете кастомизировать процесс обмена, заменив компонент ядра на свой.

Встроенные битриксовые свойства

Некоторые битриксовые свойства построены на основе компонентов. Например свойство привязки к элементу с автодополнением построено на основе компонента bitrix:main.lookup.input. Выглядит оно не очень, да и тормозит; теперь ничего не мешает этот инпут подменить на свой. Точно также можно подменить стандартный битриксовый календарь, который используется для свойства типа «Дата»

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

На самом деле, сценариев может быть довольно много. Можно попробовать поработать с комплексными и обычными компонентами, подменяя только нужные вам компоненты из состава комплексного. Или еще вариант - если вы пользуетесь чужими модулями, основанными на компонентах, то можно подменить эти компоненты сторонних разработчиков.

Но и это не все 🙂 В следующей статье познакомлю с еще одной возможностью кастомизации, которая завязана на этой фиче, но требует отдельного упоминания.