Создание модулей и компонентов в Битрикс

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

Ключевые сущности разработки — что есть что

В этой троице новички путаются чаще всего, но на самом деле отличать модули от компонентов или агентов совсем несложно:

• В модулях лежат классы, подключения к базам данных и все то, что работает в фоновом режиме и не светится посетителям. Они нужны, когда у вас появляется своя неповторимая логика, которую Битрикс из коробки делать не умеет.
• Компонент — то, что видит пользователь. Списки товаров, формы «свяжитесь с нами», карточки новостей и так далее. Компонент отвечает за отображение данных — берет информацию из модулей и выводит на экран в красивом виде. Элемент обычно может жить внутри модуля, но способен существовать и самостоятельно, если вам так нужно.
• Агентам поручают всякую скучную, но необходимую работу в фоне. К примеру, синхронизировать данные с 1С глубокой ночью, когда посетителей почти нет, рассылать письма по подписчикам в 6 утра или вычищать мусор из базы данных.

Когда мы берем сложный проект, модуль почти всегда обрастает всей троицей. Кладем туда классы в папочку lib/, добавляем пару компонентов для показа информации на сайте, и обязательно вешаем агента для фоновых процессов.

Зачем Битриксу модули и как это помогает разработчику

Ядро Битрикса с рождения заточено под модульность и создано по принципу «разделяй и властвуй». Все элементы существуют сами по себе, но при этом умеют отлично взаимодействовать:

• main — фундамент, на котором все держится.
• iblock рулит инфоблоками — нашей основной сущностью для хранения данных.
• catalog — царство товаров, прайсов и остатков.
• sale заведует всеми денежными вопросами: корзина, заказы и скидки.
• form — доставляет сообщения от пользователей.

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

Вообще, модульность — подарок судьбы для разработчиков. Один раз собрали логику, и больше к этому не возвращаетесь. Хотите включить функционал на новом проекте? Копируете папку и устанавливайте. Больше не нужен этот функционал? Отключайте.

Стандартная комплектация любого модуля

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

• Самая важная папка — install/. Здесь складируется все, что происходит от рождения и до удаления модуля. Внутри лежит файл index.php — главный установочный скрипт, в котором прописан класс с методами DoInstall (когда модуль появляется на свет) и DoUninstall (когда его отправляют в отставку). Тут же создаются таблицы в базе и регистрируются события.
• Рядом с ним прячется version.php — хранитель номера версии и даты. Нужен, чтобы понимать, пора ли обновлять элемент и что там нового появилось.
• Папка db/ — склад SQL-скриптов. Тут лежат инструкции для создания таблиц модуля и их удаления.
• Самое сердце — папка lib/. Сюда мы складываем PHP-классы в стиле D7. Здесь работает автозагрузка по неймспейсу.
• В папке admin/ формируются интерфейсы для управления вашим творением. Все, что видит администратор, когда заходит в настройки — результат работы этой папки.
• Без папки lang/ru/ вы рискуете получить белый экран сразу после установки. Здесь лежит вся текстовая начинка админки.
• Файл options.php — страница настроек модуля, позволяющая управлять его поведением без единой строчки кода.
• include.php подключается автоматически, когда система вызывает IncludeModule. Если его нет, Битрикс не заметит ваш элемент.
• И наконец class.php — главный класс. Здесь живет его бизнес-логика и основные методы, ради которых все и затевалось.

При создании модулей в Битрикс их принято именовать как перевернутый URL: зона.компания.проект. Например, ewp.custommodule. Это стандарт, который защищает вас от конфликтов одинаковых имен.

Включаем режим творца — создание модуля с нуля

Для начала определяемся с местом прописки. Вариантов два: классический путь /bitrix/modules/ или более правильный и безопасный — /local/modules/. Второй безопаснее, потому что при обновлении ядра папка bitrix перезаписывается, и ваш модуль может бесследно исчезнуть.

Прежде чем начать работу, поищите варианты в разделе «Установленные решения». Если чужое решение уже закрывает вашу задачу, берите готовое и экономьте время.

Не нашли нужного? Тогда создаем модуль своими руками. Сначала собираем обязательный набор файлов и пишем логику в install/index.php. Тут мы описываем, что должно происходить, когда кто-то нажимает заветную кнопку «Установить». Создаются таблицы в базе, регистрируются события, прописываются пользовательские типы данных. И, конечно, прописываем обратную процедуру для метода удаления.

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

Не смешивайте бизнес-логику с установочными скриптами. Если вы начнете зашивать сложную логику в install/index.php, то быстро запутаетесь, и поддержка такого модуля превратится в кошмар. Держите код чистым.

Как не навредить системе при установке модуля

И вот, модуль у вас на руках, теперь нужно добавить его в систему. Место мы уже знаем — только /local/modules/. Копируем папку туда и идем в раздел «Модули» — «Из локального репозитория». Элемент должен появиться в списке, кликайте и все встанет автоматически, если вы правильно написали установочный скрипт.

Заходите в админку, а модуля нет? Или есть, но при установке вылетает ошибка? В 90% случаев виноват или неправильный регистр в имени папки или отсутствие файла version.php в папке install. Проверьте эти два момента в первую очередь.

Боль и страдания — что может пойти не так

Мы составили для вас подборку самых частых ошибок, чтобы вы проходили мимо них с гордо поднятой головой:

• Неправильный выбор места. Про local/ вместо bitrix/ мы уже говорили, но все равно повторим. Если элемент слетит после обновления, будет обидно.
• Проблема с наследством. Написали метод DoUninstall, но забыли прописать в нем удаление таблиц. Модуль удалился, а таблицы остались висеть в базе мертвым грузом. Теперь пытаетесь установить модуль заново, и система падает с ошибкой CREATE TABLE, потому что таблицы уже существуют. Приходится чистить базу вручную.
• Неверные пути. Прописываете пути к файлам модуля абсолютными, через /bitrix/modules/новый_модуль/.... На локальном сервере все работает, на тестовом — тоже. А потом переносите проект на другой домен, и модуль разваливается, так как пути не ведут туда, куда нужно. Запомните функцию GetModuleDir — она спасет ваш модуль при любом переезде.
• Немая админка. Забыли про языковые файлы в lang/ru/ — система не нашла перевод для надписей.
• Смешение процедурного стиля и D7-подхода. Вроде все работает, но поддерживать этот гибрид — то еще удовольствие.

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

Красота — страшная сила, или зачем нужны компоненты

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

Любой компонент состоит из стандартных деталей:

• component.php — сюда стекаются все данные, здесь же происходит их обработка и подготовка к показу.
• parameters.php — с помощью этого файла вы создаете интерфейс, который потом видит тот, кто вставляет компонент на страницу.
• class.php — для тех, кто не ищет легких путей и работает в стиле D7.
• Папка templates — хранилище всего визуального. Тут лежат шаблоны, которые определяют, как именно данные будут выглядеть на странице.

Шесть шагов к идеальному компоненту

Создание компонента Битрикс — задача проще, чем родить модуль. Меньше бюрократии, но зато больше творчества. Первым делом создаем папку с именем будущего компонента. Место дислокации — /local/components/, дальше пишем component.php, прописываем всю логику: откуда брать данные, как их обрабатывать, что передавать в шаблон. Стараемся не перегружать этот файл лишней логикой — все, что можно вынести в классы, выносим.

Теперь создаем .parameters.php. Сюда выносим все настройки, которые будут доступны тому, кто вставляет компонент на страницу. Делаем подробно и всегда добавляем человеческие названия и подсказки, чтобы в будущем не гадать, что за параметр здесь спрятан.

Далее пишем description.php. Он нужен, чтобы в админке элемент отображался с человеческим названием, описанием и иконкой. Заказчики и менеджеры это оценят. Потом переходим к папке templates/.default/, в которой лежит вся верстка. Теперь осталось только подключить элемент через конструкцию $APPLICATION->IncludeComponent().

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

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

Мудрость поколений — проверенные советы

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

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

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