Разработка и кастомизация модулей в Битрикс24 (Коробка)

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

1. Архитектура Битрикс24: файловая структура, папка local и стандарты кодирования

Архитектура Битрикс24: файловая структура, папка local и стандарты кодирования

Добро пожаловать в курс «Разработка и кастомизация модулей в Битрикс24 (Коробка)». Мы начинаем погружение в мир профессиональной разработки на платформе «1С-Битрикс». Коробочная версия (Self-hosted) отличается от облачной тем, что предоставляет разработчику полный доступ к исходному коду продукта. Это открывает безграничные возможности для кастомизации, но также накладывает большую ответственность.

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

Корневая файловая структура

Когда вы открываете проект Битрикс24 через FTP или SSH, вы видите набор папок и файлов в корне сайта. Понимание назначения каждой директории критически важно для безопасности и обновляемости проекта.

!Структура корневой директории сайта на 1С-Битрикс

Рассмотрим основные элементы:

  • /bitrix — это «сердце» и «мозг» системы. Здесь находится ядро продукта, системные модули, компоненты и шаблоны по умолчанию.
  • /upload — папка для хранения загружаемых файлов. Сюда попадают картинки товаров, аватарки пользователей, документы из задач и файлы, загруженные через визуальный редактор. Обычно эту папку исключают из системы контроля версий (Git), так как ее содержимое меняется динамически в процессе работы портала.
  • /local — папка для разработчиков. Именно здесь будет происходить вся магия кастомизации. Если этой папки нет в корне, её необходимо создать вручную.
  • index.php — точка входа на главную страницу портала.
  • .htaccess — файл конфигурации веб-сервера Apache (или его аналог для Nginx), отвечающий за перенаправление запросов и настройки безопасности.
  • Публичная часть

    Все файлы и папки, лежащие в корне сайта (кроме служебных bitrix, local, upload), относятся к публичной части. Это те страницы, которые видит пользователь в браузере. Например, папка /company/ отвечает за раздел «Компания», а /crm/ — за CRM-систему.

    Структура публичной части формирует URL-адреса сайта. Если вы создадите папку /test/ и положите в неё index.php, эта страница будет доступна по адресу ваш-портал.рф/test/.

    Ядро системы и правило «Не трогай /bitrix»

    Самое важное правило разработки на Битрикс24 звучит так:

    > Никогда, ни при каких обстоятельствах не изменяйте файлы внутри папки /bitrix.

    Почему это так важно?

    * Обновления системы. Платформа 1С-Битрикс регулярно обновляется. Процесс обновления работает просто: система скачивает новые версии файлов и перезаписывает старые в папке /bitrix. Если вы внесли правки в системный модуль, первое же обновление сотрет ваш труд. * Техническая поддержка. Если вы модифицировали ядро, вендор (1С-Битрикс) имеет право отказать вам в технической поддержке до тех пор, пока целостность ядра не будет восстановлена. * Безопасность. Изменения в ядре могут создать уязвимости, которые не будут закрыты стандартными патчами безопасности.

    В папке /bitrix находятся:

    * /bitrix/modules — системные модули (main, iblock, crm, socialnetwork и др.). * /bitrix/components — стандартные компоненты. * /bitrix/templates — стандартные шаблоны сайта. * /bitrix/admin — административная панель.

    Папка /local: территория разработчика

    Для безопасной кастомизации в архитектуре Битрикс24 предусмотрен механизм приоритетности. Система устроена так, что при подключении ресурсов она сначала ищет их в папке /local, и только если не находит — обращается к /bitrix.

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

    1. /local/modules

    Здесь размещаются ваши собственные модули. В рамках этого курса мы будем работать именно с этой директорией. Создание модуля позволяет инкапсулировать логику, установщики БД и события в единую структуру.

    2. /local/components

    Сюда помещаются кастомные компоненты. Компонент — это логический блок, отвечающий за вывод информации (например, список новостей) или выполнение действия (например, форма обратной связи). Вы можете создавать свои компоненты в пространстве имен, отличном от bitrix (например, mycompany:news.list).

    3. /local/templates

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

    4. /local/php_interface

    Одна из самых важных директорий для глобальных настроек. Здесь обычно располагают:

    * init.php — файл, который подключается при каждой загрузке любой страницы сайта. Это идеальное место для подключения обработчиков событий (event handlers), автозагрузки классов (autoload) и объявления глобальных констант. * dbconn.php — параметры соединения с базой данных (хотя физически он часто лежит в /bitrix/php_interface, его копия или настройки могут влиять на среду).

    !Приоритет загрузки файлов из папки local

    Стандарты кодирования в Битрикс24

    Битрикс24 — система с долгой историей. В ней сосуществуют два архитектурных подхода:

  • Старое ядро (Old Core) — процедурный стиль, классы с префиксом C (например, CUser, CIBlockElement). Используется глобальная переменная _SERVER['DOCUMENT_ROOT'] . '/local/vendor/autoload.php')) {
  • require_once eventManager = \Bitrix\Main\EventManager::getInstance();

    // Когда добавляется пользователь, вызываем метод нашего класса $eventManager->addEventHandler( 'main', 'OnAfterUserAdd', ['\My\Module\UserHandler', 'onAdd'] ); `

    Резюме

  • Битрикс24 имеет четкую файловую структуру. Публичная часть отвечает за URL, ядро (/bitrix) — за логику.
  • Папка /bitrix неприкосновенна. Любые изменения в ней будут уничтожены при обновлении.
  • Вся кастомизация ведется в папке /local, которая имеет приоритет над /bitrix.
  • Современная разработка требует использования ядра D7, пространств имен и кодировки UTF-8.
  • Файл init.php` служит для глобальной конфигурации и регистрации событий, но код логики следует выносить в классы.
  • В следующей статье мы перейдем от теории к практике и создадим каркас вашего первого модуля, используя изученную структуру.

    2. Кастомизация компонентов: шаблоны, result_modifier и component_epilog

    Кастомизация компонентов: шаблоны, result_modifier и component_epilog

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

    В терминологии 1С-Битрикс эти блоки называются компонентами. В этой статье мы детально разберем, как правильно кастомизировать компоненты, не ломая ядро, и какую роль в этом играют файлы template.php, result_modifier.php и component_epilog.php.

    Что такое компонент и шаблон?

    Для начала разделим понятия:

  • Компонент — это контроллер. Это PHP-код (обычно скрытый в ядре), который принимает параметры, делает запросы к базе данных, обрабатывает права доступа и формирует массив данных.
  • Шаблон компонента (Template) — это представление (View). Это папка с файлами, которая отвечает за то, как полученные данные будут показаны пользователю (HTML, CSS, JS).
  • Стандартные компоненты лежат в /bitrix/components/. Трогать их нельзя. Но мы можем подменить их шаблон, скопировав его в /local/templates/.

    !Схематичное изображение передачи данных от логики компонента к его визуальному представлению

    Анатомия шаблона компонента

    Когда вы копируете шаблон компонента (вручную или через режим правки) в папку /local, вы получаете директорию с набором файлов. Давайте разберем, за что отвечает каждый из них и в каком порядке они выполняются.

    Стандартная структура папки шаблона выглядит так:

    * result_modifier.php (необязательный) * template.php (обязательный) * component_epilog.php (необязательный) * style.css * script.js * .parameters.php * lang/ (папка с языковыми фразами)

    1. template.php — Лицо компонента

    Это главный файл шаблона. Именно здесь пишется HTML-верстка. В этом файле вам доступны два главных массива:

    * arParams — массив с настройками компонента (сколько новостей выводить, какой формат даты использовать).

    Золотое правило: В template.php не должно быть сложной PHP-логики, запросов к базе данных или тяжелых вычислений. Этот файл должен заниматься только выводом данных.

    Пример плохого кода в template.php:

    В файле component_epilog.php:

    Таким образом, мы разделили логику проверки (PHP) и логику отображения (HTML).

    Резюме

    Правильная кастомизация компонентов в Битрикс24 строится на трех китах:

  • result_modifier.php — здесь мы готовим данные. Получаем недостающую информацию, форматируем даты, сортируем массивы. Этот файл выполняется до построения HTML.
  • template.php — здесь мы только выводим данные. Никаких тяжелых запросов. Только циклы и условия отображения.
  • component_epilog.php — здесь мы выполняем действия, которые нельзя кешировать (счетчики, динамические заголовки, работа с сессией).
  • Соблюдение этой структуры гарантирует, что ваш проект будет работать быстро (благодаря кешированию) и его будет легко поддерживать другим разработчикам.

    В следующей статье мы углубимся в создание собственных компонентов с нуля и разберем класс CBitrixComponent.

    3. Событийная модель: перехват системных событий и изменение бизнес-логики

    Событийная модель: перехват системных событий и изменение бизнес-логики

    В предыдущих статьях мы научились создавать структуру для наших доработок в папке /local и кастомизировать внешний вид компонентов. Однако, часто возникает задача изменить не то, как выглядит элемент, а то, как работает система. Например, запретить удаление важных сделок, автоматически генерировать логины для пользователей или отправлять данные в 1С при изменении статуса заказа.

    Для решения таких задач в Битрикс24 существует событийная модель. Это мощный механизм, позволяющий внедрять свой код в процесс выполнения стандартных операций системы, не нарушая целостность ядра.

    Что такое событие?

    Архитектура Битрикс24 построена на принципе, который в программировании называется Observer (Наблюдатель) или Hook (Хук). Когда в системе происходит что-то важное (добавление пользователя, обновление элемента инфоблока, отправка письма), ядро «выбрасывает» событие.

    Представьте это как радиосигнал. Система кричит в эфир: «Внимание! Я собираюсь добавить нового пользователя!». Если ваш модуль настроен на «прослушивание» этой частоты, он может перехватить сигнал и выполнить свой код.

    !Схема перехвата управления через событийную модель

    Типы событий: До и После

    Глобально все события можно разделить на две большие группы:

  • События «OnBefore» (До действия)
  • Они срабатывают перед тем, как данные будут записаны в базу данных. Это самый полезный тип событий для валидации и модификации данных. * Возможности: Можно изменить данные (например, принудительно сделать фамилию с большой буквы) или полностью отменить действие (выдать ошибку и не дать сохранить элемент). Примеры:* OnBeforeUserAdd, OnBeforeIBlockElementUpdate, OnBeforeCrmDealAdd.

  • События «OnAfter» (После действия)
  • Они срабатывают после того, как запись уже попала в базу данных. * Возможности: Идеально подходят для логирования, отправки уведомлений, синхронизации с внешними системами. Отменить само действие здесь уже нельзя (так как оно уже свершилось). Примеры:* OnAfterUserAdd, OnAfterIBlockElementDelete, OnAfterCrmCompanyUpdate.

    Регистрация обработчиков событий

    Чтобы ваш код сработал, нужно «подписаться» на событие. В современном ядре D7 для этого используется класс \Bitrix\Main\EventManager.

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

    Синтаксис регистрации

    > Важно: Никогда не пишите логику обработки внутри анонимных функций в init.php. Это делает код нечитаемым и сложным для отладки. Всегда выносите логику в методы классов вашего модуля.

    Старое и новое ядро: в чем подвох?

    Битрикс24 — система с историей, поэтому в ней сосуществуют два подхода к событиям. Это часто сбивает с толку новичков.

    1. События старого ядра (Old Core)

    Большинство событий инфоблоков (iblock), каталога (catalog) и главного модуля (main) работают по старой схеме. Они передают данные в обработчик в виде массива параметров.

    Пример обработчика (старое ядро):

    Как понять, какое событие перед вами? Самый надежный способ — открыть документацию к конкретному событию или заглянуть в исходный код модуля в папке /bitrix/modules/.

    Практический кейс: Запрет изменения ответственного в Сделках

    Давайте решим реальную бизнес-задачу. Руководитель отдела продаж хочет запретить менеджерам менять поле «Ответственный» в сделках CRM, если сумма сделки превышает 1 миллион рублей. Менять ответственного может только администратор.

    Шаг 1. Поиск события

    Нам нужно событие модуля crm, которое срабатывает до обновления сделки. Это OnBeforeCrmDealUpdate.

    Шаг 2. Регистрация в init.php

    Шаг 3. Реализация логики

    Создадим класс в /local/modules/local.crm/lib/dealhandler.php (путь условный, зависит от структуры вашего модуля).

    Как отлаживать события?

    Самая большая сложность при работе с событиями — понять, что именно приходит в переменной event. Поскольку события срабатывают «под капотом», вы не можете просто сделать var_dump() и увидеть результат на экране.

    Для отладки используйте логирование в файл:

    После выполнения действия откройте созданный файл и изучите структуру данных.

    Резюме

  • Событийная модель позволяет изменять логику работы системы без редактирования ядра.
  • События делятся на OnBefore (можно отменить/изменить) и OnAfter (только уведомления/логи).
  • Регистрация происходит через EventManager в файле init.php.
  • Обработчики бывают двух типов: принимающие массив по ссылке (старое ядро) и принимающие объект Event (D7).
  • Для отладки всегда используйте запись в лог-файл.
  • В следующей статье мы разберем работу с базой данных в Битрикс24: как правильно писать запросы, использовать ORM и почему прямые SQL-запросы — это крайняя мера.

    4. Создание собственного модуля: структура файлов, инсталлятор и автозагрузка классов

    Создание собственного модуля: структура файлов, инсталлятор и автозагрузка классов

    В предыдущих статьях мы прошли путь от понимания файловой структуры Битрикс24 до работы с событиями и кастомизации компонентов. Мы выяснили, что файл init.php — это удобное место для быстрых правок, но по мере роста проекта он превращается в «свалку» кода, который сложно поддерживать.

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

    Зачем нужен модуль?

    Модуль в архитектуре Битрикс24 — это изолированный пакет функционала. В отличие от разрозненных скриптов в php_interface, модуль обладает рядом преимуществ:

  • Инкапсуляция: Весь код (классы, компоненты, административные страницы, таблицы БД) лежит в одной папке.
  • Управление зависимостями: Вы можете указать, что ваш модуль требует наличия других модулей (например, crm или sale).
  • Версионность: Вы можете выпускать обновления и накатывать их через стандартный механизм.
  • Автозагрузка: Использование стандарта PSR-4 для автоматического подключения классов.
  • Именование и расположение

    Все пользовательские модули должны располагаться в директории /local/modules/. Если вы разрабатываете решение для Маркетплейса, оно должно лежать в /bitrix/modules/, но для кастомной разработки (in-house) используется папка local.

    Идентификатор модуля (ID) состоит из двух частей, разделенных точкой: partner.module

    * partner — код партнера или компании (например, mycompany, local, dev). * module — название конкретного модуля (например, integration, tools, crmfix).

    > Совет: Для внутренних разработок часто используют префикс local. Например: local.b24utils.

    Файловая структура модуля

    Чтобы система распознала вашу папку как модуль, она должна иметь строго определенную структуру. Рассмотрим минимально необходимый набор файлов для современного модуля на ядре D7.

    !Структура файлов и папок стандартного модуля Битрикс

    Разберем назначение каждой директории:

  • install/ — Содержит файлы, необходимые для установки модуля.
  • * index.php — Паспорт модуля. Класс с описанием и методами установки/удаления. * version.php — Номер версии и дата релиза.
  • lib/ — Основная папка для классов модуля (логика). Здесь работает автозагрузка D7.
  • lang/ — Языковые файлы. Битрикс — мультиязычная система, поэтому хардкодить русский текст в PHP-файлах считается плохим тоном.
  • include.php — Файл, который подключается при инициализации модуля (обычно используется для регистрации классов старого образца или глобальных констант).
  • Создаем модуль шаг за шагом

    Допустим, мы создаем модуль с ID local.learning.

    Шаг 1. Файл версии

    Создайте файл /local/modules/local.learning/install/version.php. Он должен возвращать массив с версией и датой.

    И соответственно, метод удаления UnInstallEvents:

    Теперь при нажатии кнопки «Установить» обработчик запишется в базу данных. Даже если init.php будет пуст, событие сработает.

    Подключение модуля в коде

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

    Обычно эту проверку делают в начале скрипта:

    Резюме

    Создание собственного модуля — это ключевой навык для разработчика на Bitrix Framework. Это переводит вас от хаотичного редактирования файлов к системному инжинирингу.

  • Модули лежат в /local/modules/.
  • Главный файл — install/index.php (класс-наследник CModule).
  • Логика (классы) лежит в /lib/ и загружается автоматически по PSR-4.
  • События регистрируются один раз при установке модуля через registerEventHandler.
  • В следующей статье мы углубимся в работу с базой данных внутри модуля: научимся создавать свои таблицы через ORM и работать с ними без прямых SQL-запросов.

    5. Работа с данными: ORM, D7 и интеграция с Highload-блоками

    Работа с данными: ORM, D7 и интеграция с Highload-блоками

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

    В старом ядре Битрикс (Old Core) разработчики писали прямые SQL-запросы через глобальный объект result = ScheduleTable::add([ 'LESSON_NAME' => 'Введение в ORM', 'LESSON_DATE' => new DateTime('25.10.2023 18:00:00'), 'ACTIVE' => 'Y' ]);

    if (id = id; } else { // Получаем массив ошибок result->getErrorMessages(); print_r(rsData = ScheduleTable::getList([ 'select' => ['ID', 'LESSON_NAME', 'LESSON_DATE'], // Какие поля выбрать 'filter' => ['=ACTIVE' => 'Y', '>ID' => 5], // Условия (WHERE) 'order' => ['LESSON_DATE' => 'DESC'], // Сортировка 'limit' => 10, // Лимит записей 'cache' => ['ttl' => 3600] // Кеширование запроса на 1 час ]);

    while (rsData->fetch()) { echo "Урок: " . id = 15; id, [ 'LESSON_NAME' => 'Новое название урока' ]); php id); php use \Bitrix\Highloadblock\HighloadBlockTable;

    // 1. Подключаем модуль \Bitrix\Main\Loader::includeModule('highloadblock');

    // 2. Получаем данные о HL-блоке по его ID (например, ID = 1) entity = HighloadBlockTable::compileEntity(entityDataClass = rsData = el = el); } `

    Этот код универсален. Переменная $entityDataClass содержит имя виртуального класса, который имеет те же методы add, update, delete, getList, что и наш ScheduleTable.

    !Процесс компиляции сущности Highload-блока для работы через ORM

    Почему нельзя использовать прямые SQL-запросы?

    Иногда кажется, что написать SELECT * FROM my_table проще. Но использование ORM дает критические преимущества:

  • Безопасность: ORM автоматически экранирует данные, защищая от SQL-инъекций.
  • События: При использовании add/update/delete через ORM срабатывают системные события (OnBeforeAdd, OnAfterAdd). Прямой SQL-запрос идет в обход событий, что может сломать логику других модулей.
  • Кеширование: Метод getList имеет встроенную поддержку тегированного кеша.
  • Переносимость: Если Битрикс решит сменить базу данных (например, на PostgreSQL), ваш код на ORM продолжит работать, а SQL-запросы придется переписывать.
  • Резюме

  • Вся работа с данными в модулях должна вестись через D7 ORM.
  • Каждая таблица описывается классом-наследником Bitrix Main Entity DataManager.
  • Метод getMap() определяет поля таблицы и их типы.
  • Для выборки данных используется универсальный метод getList с параметрами select, filter, order, limit`.
  • Highload-блоки — это удобная обертка над пользовательскими таблицами, позволяющая работать с ними через тот же синтаксис ORM, предварительно скомпилировав сущность.
  • Теперь ваш модуль умеет не только встраиваться в систему, но и надежно хранить свои данные. В следующей статье мы поговорим о том, как создать пользовательский интерфейс для вашего модуля в административной панели Битрикс24, чтобы управлять этими данными было удобно.