Многие компании в определенный момент приходят к тому, что ряд процессов в бизнесе нужно автоматизировать, чтобы не потерять свое место под солнцем и своих заказчиков. Поэтому все чаще клиенты начинают «оцифровывать» свой бизнес.
Для этой цели есть разные платформы, Битрикс24 — одна из самых популярных. Скорость развития и появления новых фич, качественная поддержка и богатый набор инструментов, который даже с минимальной кастомизацией покрывает базовые потребности большинства разных компаний, делает эту платформу практически идеальным решением для бизнеса.
Но, увы, не для разработчиков, особенно начинающих.
Специалисты пишут обучающие статьи по 1С-Битрикс и разным модулям системы, но после их прочтения у новичков все равно нет общей картинки и понимания, как же все устроено на этой платформе. В интернете есть статьи про best practice разработки на фреймворках, но разработку на Б24 обходят стороной. Есть и компании, которые научились делать качественный продукт, но они держат свои наработки в тайне.
Если хотите узнать, как можно работать с Битрикс24, сохранив при этом исходный цвет волос, добро пожаловать под кат.
Юлия Силантьева — ведущий разработчик Битрикс24 в digital-агентстве полного цикла ITECH.
Что из себя представляет Битрикс24
Наверное, все, кто по долгу службы или из интереса хоть раз сталкивался с разработкой под Битрикс24, знают продукт 1С-Битрикс: Управление сайтом (БУС). Это CMS для создания сайтов или, по определению самого Битрикса, система управления интернет-ресурсами.
Но мало кто знает, что корпоративный портал Битрикс24 — это сервис, написанный на 1С-Битрикс.
Битрикс24 имеет 2 решения: облачное и коробочное. Отличаются они, как понятно из названия, местом размещения кода портала: на серверах Битрикс или на сервере клиента. Коробка дает больший простор для фантазии, но имеет более дорогую лицензию и нуждается в поддержке серверов, а облако стоит дешевле, но имеет ряд ограничений на кастомизацию.
В целом же дорабатывать можно как облачные, так и коробочные версии. Какое решение использовать, зависит от нужд клиента.
В рамках этой статьи я хочу более детально рассмотреть общие подходы к разработке на коробочной версии Битрикс24.
Коробочное решение: архитектура продукта
Внутри сервиса лежит Bitrix Framework, являющийся ядром сайта.
Bitrix Framework содержит модули и компоненты:
- Модуль — это модель данных и API для доступа к этим данным. Весь продукт структурно разбит на модули, отвечающие за ту или иную область применения: Интранет, Задачи, CRM, Бизнес-процессы и другие.
- Компонент — это контроллер и представление для использования в публичном разделе. Компонент с помощью API одного или нескольких модулей манипулирует данными. Шаблон компонента (представление) выводит данные на страницу. Компоненты входят в состав модулей, но решают более узкую, частную задачу, например, выводят список задач или карточку сделки. Вся публичная часть сервиса построена на вызове со страницы различных компонентов. К примеру, страница списка сделок CRM состоит из компонентов меню, фильтра и самого списка.
Ядро Bitrix Framework — файлы, находящиеся в директории /bitrix. Вносить изменения в ядро нельзя (Вообще. Никогда. Даже не думайте об этом) в силу нескольких причин:
- при обновлении системы внесенные изменения затрутся;
- при изменении ядра владелец лицензии потеряет право на техническую поддержку;
- при изменении ядра разработчиком сайта система может работать некорректно, так как ядро — сложная структура, требующая учета работы всех модулей.
Однако есть еще один большой нюанс.
Портал Битрикс24, как и любой другой сайт, написанный на 1С-Битрикс, включает в себя шаблон сайта, публичную часть (т. е. разделы и страницы), компоненты и шаблоны компонентов. А отличается он от обычного сайта тем, что при установке обновлений все вышеперечисленное также обновляется. Поэтому публичную часть, шаблон Битрикс24 и стандартные компоненты также можно считать ядром Битрикс24. А это значит, что в них тоже нельзя вносить изменения (как минимум потому, что они будут удалены при очередном обновлении).
Но лазейки все же есть, и безболезненно внести изменения реально.
Обновляемость
Обновления продукта очень важны. Они решают проблемы с безопасностью, закрывают имеющиеся баги (правда, иногда тут же плодят новые :) ). Иногда с обновлениями прилетают новые крутые плюшки.
Крупные новинки Битриксоиды презентуют на своих конференциях, которые проводят каждые полгода (последняя прошла в апреле в формате онлайн), но выпускают их патчами практически каждый день. Держать руку на пульсе помогает email-рассылка об обновлениях. Подключить ее можно в админке любого портала на Битрикс24: Marketplace -> Обновление платформы -> Дополнительно -> Подписаться на получение информации об обновлениях по почте.
Битрикс советует устанавливать обновления, как только они становятся доступными. Но я бы рекомендовала этого совета придерживаться не всегда. Желательно устанавливать обновления в моменты минимальной нагрузки на сервер, например, в выходные или ночью — по закону Мерфи, в момент, когда требуется сделать все быстро и незаметно, Битрикс падает с ошибкой при обновлении. :) Конечно, это бывает нечасто, но подстраховаться не помешает. И не забывайте делать бекапы перед запуском обновлений.
Принципы кастомизации
Вся разработка должна вестись в одной папке — /local.
Чтобы добавить свой функционал в сайт, написанный на БУС, достаточно найти нужный компонент, скопировать его в папку /local, кастомизировать класс и шаблон компонента.
На Битрикс24 этот подход является в корне неверным.
Во-первых, если скопировать шаблон в каталог /local, система всегда будет использовать его вместо стандартного. Это означает, что после очередного обновления клиент не увидит новых функций, которые могли быть добавлены в этот компонент, а также не будут исправлены ошибки, если они есть. Вручную поддерживать актуальность компонентов сложно, а если изменения носили глобальный характер, то невозможно.
Во-вторых, компоненты сервиса представляют собой целостную систему, и их код написан, исходя из предположения, что во всей системе используются оригинальные шаблоны. Это означает, что кастомизированный шаблон может привести к информационной несовместимости с остальными частями системы и стать источником трудно уловимых ошибок.
Что же в таком случае делать разработчику, которому необходимо изменить или добавить какую-то логику?
Есть несколько вариантов решения проблемы:
- воспользоваться определенными разрешенными точками встройки в интерфейс и отложенными функциями;
- изменить результат исполнения компонента и добавить к нему свои стили и скрипты;
- создать свой бизнес-процесс или настроить роботов;
- привязаться к событиям на стороне PHP или JS;
- создать свой тип поля (например, виджет);
- написать свое приложение;
- написать свой модуль.
Для каждой задачи приходится подбирать наиболее подходящий инструмент.
Local
Основная папка, куда может и должен запустить руки разработчик, — /local. Изначально на проекте ее нет, так что наполнять папку можно по своему усмотрению, но в части путей важно следовать указаниям Битрикс, иначе платформа не увидит кастомизированные компоненты и модули.
Предлагаем универсальную структуру папки /local:
- activities содержит действия бизнес-процессов.
- components содержит самописные компоненты (не путать с кастомизированными компонентами Битрикс!).
- css, fonts, images, js содержат соответствующие файлы и ресурсы.
- modules содержит самописные модули системы. Все независимые блоки кода следует группировать в модули для облегчения дальнейшего сопровождения, подключения и использования данного кода.
- php_interface содержит php-скрипты. Здесь могут храниться обработчики ajax-запросов, классы и файлы, не принадлежащие ни к одному модулю, обработчики событий.
- init.php — специальный файл в рамках структуры Bitrix Framework. Он автоматически подключается в прологе. Файл может содержать в себе инициализацию обработчиков событий, подключение дополнительных функций, объявление библиотек. Чтобы init.php не превращался в свалку непонятного кода, следует размещать код, логически группируя по файлам и классам, а в init.php оставлять только подключения. Кстати, подключать классы и файлы можно через модули, __autoload Битрикса или через composer.
- templates содержит кастомизацию компонентов Битрикс.
- tools может содержать исполняемые через cron файлы.
Структура очень гибкая: когда это необходимо (например, при появлении новых задач), можно дополнить папку новыми разделами, а не тратить время на разработку новой структуры.
При обработке папок приоритет всегда у папки /local перед /bitrix. Это означает, что, если в /local/templates/ и /bitrix/templates/ находиться шаблоны сайта с одинаковым названием, то подключится шаблон из /local.
Отсюда следует важное замечание: чтобы Битрикс понимал, что следует забирать кастомизированные шаблоны компонентов из папки /local, она должна обладать определенной структурой:
/local/templates/шаблон_сайта/components/namespace/название_компонента/название_шаблона/.
При этом папка шаблона сайта в /local (речь идет о Битрикс24, а не БУС) должна содержать шаблон, созданный компанией Битрикс (/bitrix/templates/bitrix24/). Только в этом случае система поймет, что необходимо подключить компонент из /local.
Что еще важно иметь в виду при разработке?
1. Все языковые переменные обязательно должны храниться в соответствующих ланговых файлах. Языковой файл представляет из себя php-скрипт, хранящий переводы языковых фраз на тот или иной язык. Данный скрипт состоит из массива $MESS, ключи которого — идентификаторы языковых фраз, а значения — переводы на соответствующий язык.
Для каждого языка существует свой набор языковых файлов, хранящихся в подкаталогах /lang/ структуры файлов системы или модуля.
Почему важно выносить все тексты в отдельные файлы? При переводе вашего портала на другой язык будет достаточно собрать и перевести только фразы из языковых файлов, создав при этом новые разделы для соответствующего языка. Не нужно будет искать места, где могут встречаться тексты в коде, и вносить изменения непосредственно в код портала.
Подробнее о том, как пользоваться языковыми файлами, написано в официальном документе.
2. При работе с компонентами не надо обращаться к базе напрямую. Концепция работы с продуктом предполагает работу с данными через функции API. Структура данных может меняться от версии к версии, а функции сохраняют обратную совместимость. Битрикс настоятельно не рекомендует использовать прямые запросы к БД, так как это может нарушить целостность данных и привести к неработоспособности системы.
Более того, если речь идет о системных таблицах самого Bitrix Framework, это не просто не приветствуется, а в принципе не поддерживается. Необходимо работать с ними через API системы, так как физическая структура БД может измениться, а работа даже самого древнего API гарантирована.
3. Версионировать работу над проектом с помощью системы контроля версий. При этом, в силу особенностей разработки на Битрикс, имеет смысл предусмотреть «особенность» и в настройке репозитория для проекта: разделять файлы ядра и кастомизируемые.
4. Читайте доки. По многим локальным вопросам, особенно общим с 1С-Битрикс, можно найти отдельные статьи или документацию. Для разработчиков, привыкших гуглить сразу на английском, будет сюрпризом, что большинство статей написано на русском. :)
И необходимо помнить золотое правило, которого советуют придерживаться опытные разработчики: меньше кода — меньше багов.
Итого
Сегодня можно наблюдать дисбаланс между спросом и предложением на рынке разработки под Битрикс24. Потребность в разработчиках стремительно растет, а многие специалисты не хотят связываться с продуктом от Битрикс, так как знакомы с его старшим и уже практически почившим детищем — БУС.
Но не так страшен черт, и даже начинающие разработчики смогут освоиться и выпускать качественный продукт, который «не стыдно пацанам показать» © пользователь habr.
