Мультисайтовый проект Битрикс

Данный регламент служит руководством к разработке новых и приведению к общему виду существующих проектов на 1С-Битрикс.

Создание любого интернет-ресурса, это совокупность работ, для выполнения которых нужны узкопрофильные специалисты (верстальщик, дизайнер, копирайтер, программист, оптимизатор). Процесс разработки сайта объёмный и трудоёмкий, особенно для неопытного пользователя.

Стек технологий

Большинство проектов работает в виде link-проекта на BitrixVM, базовым является стек именно вокруг этой виртуальной машины, а именно:

• CentOS нужно корректно настроить мультисайтовый сервер
• Apache + NGiNX конфигурирование как правило не требуется
• MySQL практически не требует вмешательства разработчика/администратора
• PHP 8.x
• Пакеты и ПО которые бывает также требуютсяredis, memcached, xmlreader/writer

При разработке на платформе 1С-Битрикс предпочтительно использовать API D7, регламента как такового нет, но есть рекомендации от самих разработчиков Битрикс. Как правило, не требуется писать велосипедов, достаточно кастомизировать шаблоны компонентов и изредка править логику, однако не стоит мешать логику и представление с контентом на статичных страницах, часть такой страницы может быть потеряна при работе контент-менеджером. Проект должен быть ремонтопригодным, завершённым, стабильным и при этом позволять работать контент-менеджеру со статичным контентом в режиме правки, настраивать меню, компоненты на страницах через стандартный интерфейс Битрикс.

Рекомендуемый стек используемый при разработке новых проектов:

• PHP 8.x
• HTML5
• CSS3
• Нативный JS
• Bootstrap, есть в ядре Битрикс, пусть и не самый свежий, но рабочий

Я не приветствую сторонние библиотеки не входящие в ядро Битрикс, однако также не сильно будут рад jQuery, даже если он тянеться из ядра. Стили проекта должны подключаться после Bootstrap, замещая стили UI только в случае крайней необходимости.

Для интеграций с API желательно не использовать сторонних методов, есть httpClient из ядра, который прекрасно работает.

Соблюдение стандартов

Собственно, прежде всего это рекомендации Битрикс. Код должен соответствовать требованиям PSR. Обратите внимание на PSR-1 и PSR-12, можно посмотреть на английском и русском языках.

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

Парадигмы БЭМ и ООП это классно, но не является стандартом, рекомендую не усложнять проект.

Архитектура проекта, местоположение и именование файловой структуры

Для разработки, развёртывается мультисайтовый сервер BitrixVM или аналогичная система на ПК разработчика локально, либо на специальном сервере для разработки. Это означает, что проект с индексом s1 несёт в себе ядро, а все последующие проекты создаются через меню /root/menu.sh как ссылки link, подключаясь к той же базе данных.

Пространство localspace для файловой структуры каждого проекта находится в отдельном разделе с именованием домена.

В корне основного раздела проекта ничего лишнего, только файлы и разделы сайта, без мусора и статичных файлов. Общая папка /image/ из ядра, как и upload, может дополняться статичными файлами, если располагать их в подпапке с именованием домена (не просто проекта, а именно домена). В структуре проекта отсутствуют разделы ядра, они подключаются симлинками автоматически, если проект создан через меню.

Представление в которое входит дизайн, фронтенд, всё что касается стилизации и вёрстки шаблона сайта, находится в /local/templates/%template_name%/, в разделе темплейта проекта.

Кастомизированные компоненты и модули соответственно должны находиться в /local/components/, либо в /local/modules/.

Если требуется изменить логику ядра, делать это нужно в /local/php_interface/.

Инфоблоки и HL-блоки

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

• Инфоблоки SITENAME.RU_IBNAME_SUFFIX
• HL-блокиSitenameRuHlnameSuffix

Суффикс в названии – это опция, если требуется для лучшего понимания.

Инфоблоки в идеале должны хранить данные в отдельных таблицах.

HL-блоки дают преимущество в скорости работы только при больших объёмах списковых данных.

Статические части проекта без содержания критически важных скриптов, стилей и участков кода выносятся в инклюды (подключаемые области) – это критично для безопасной работы контент-менеджеров. Поскольку в режиме правки страница не может быть сломана контент-менеджером, если на ней есть только контент и компоненты – строить разделы и страницы стоит именно таким образом, вынося на сложных страницах участки контента в отдельные инклюд (подключаемые области).

Header и Footer строится в отдельном файле темплейта и разумеется там другие правила, однако редактируемым должно быть: меню, логотип, если есть контакты и другие элементы, которые имеют статичный вид и могут меняться со временем. Если в шапке интернет-магазина есть корзина, либо личный кабинет в миниатюре или ссылка – это спокойно можно унести в шаблон компонента.

Версионность кода проекта

В своей работе я использую внутренний гит gitlab, где находится три основные ветки:

• master
• test
• prod

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

Приёмка проекта

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

Обязательное тестирование перед сдачей проекта. Разворачиваю проект самостоятельно в виде мультисайтового проекта, с проведением миграций данных. Также проважу валидацию вёрстки и тест Google PageSpeed, а так-же проверяю консоль на наличие ошибок.