# Разработка тиражных решений

Свои тиражные решения можно выпусать как:

• Дистрибутивы
  Так же, как битрикс выкладывает дистрибутивы для всех своих редакций или отраслевых решений
• Модули тиражных решений для Marketplace

# Процесс создания тиражного решения

1. Разрабатываем обычный сайт!
   Есть ньюансы, но в целом этапы мало отличаются от частной разработки
2. Наполняем демонстрационными данными
3. Тестируем сайт
4. Собираем мастер и модуль
5. Пушим модуль в git
6. Еще раз тщательно тестируем модуль, мастер и сайт, созданный мастером
7. Проходим модерацию и публикуем решение

# Разработка

Первым делом создаём болванку модуля. На этом этапе модуль ещё ничего не содержит, в процессе все собственные классы, функции, обработчики событий нужно добавлять в модуль, bitrix/php_interface и папку local не используем.

• Разрабатываем в cp1251
  По требованию Marketplace все решения должны загружаться в этой кодировке. Так не придется конвертировать все файлы для сборки модуля — сэкономим время.

  Перекодировка из utf-8 задача не тривиальная, может привоидть к ошибкам. Поэтому, Разрабатываем в cp1251!

• Кириллицу везде, кроме публичной части, заменяем на языковые фразы В модулях Marketplace это обязательно: при установке на сайт в кодировке utf-8 файлы модуля перекодируются только в подпапках <код языка>/)

• Нельзя использовать ID Заменяем их на символьный/внешний код или на функцию получения ID по символьному коду. Актуално для всех сущностей БД: инфоблоков, свойств, разделов, значений списков, групп пользователей и т.п.

• Всё меняющееся в настройках лучше выносить в БД Так мы сможем менять настройки (название сайта, контакты и т.п.) в одном месте, не придется перезаписывать файлы с контентом в публичной части

• Модуль и мастер может использовать другие модули из Marketplace
  С некоторыми ограничениями:

  • Если модуль «чужой», он должен быть бесплатным, свой может быть платным, но с пробным периодом
  • Есть особенность процедуры установки/удаления модуля, которую не все реализуют правильно, что мешает автоматически скачать и установить модуль в составе тиражного решения

• Есть практика использования composer в модулях
  Можно использовать обычные пакеты с библиотеками и собственные компоненты, переиспользуемые в разных тиражках (citrus:iblock.element.form, например)

# Демо-данные

Для таражки должны быть полностью заполенны осмысленными контентом:

• Инфоблоки
• Тексты на статических страницах

Не должно быть никаких Text here... и прочих lorem, ipsum.

# Тестирование

Все новые решения перед публикацией в Marketplace проходят проверку в 1С-Битрикс. Своей очереди на модерацию приходится ждать от двух недель до месяца.

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

Модераторы обязательно проверяют:

• Наличие битых ссылок
• Наличие поблем с кодировкой (из-за не вынесенных в языковые файлы сообщений) Поэтому решение нужно проверять как минимум в двух вариантах: cp1251 и utf-8
• Наличие предупреждений (E_WARNING) на любых страницах решения или в процессе установки Показ таких предупреждений по-умолчанию отключен. Нужно включить и убедиться в их отсутствии.
• Наличие js-ошибок в консоли браузера
• Неработающие формы, любые грубые ошибки в логике работы

Для выявления битых ссылок, ошибок js и php (в т.ч. E_WARNING) у нас есть специальный скрипт, который можно запускать на развернутом мастером решении: https://git.citrus-soft.ru/citrus/checker

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

# Что из себя представляет мастер?

Задача мастера: программно воссоздать или повтороить всё, что делал разработчик при создании сайта.

Мастера тиражных решений содержат:

1. Шаги мастера по заданию настроек будущего сайта
2. Шаблоны сайта
3. Цветовые схемы
4. Публичную часть будущего сайта
5. Сервисы для настройки БД, разворачивания и настройки модулей

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

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

Сборку мастеров можно и нужно автоматизировать: многие вещи повторяются от проекта к проекту.

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

Собственно сервисы и выполняют всю работу по развертыванию сайта

Процесс настройки в мастере состоит из коротких, выполняющиеся последовательно скриптов, разбитых на группы функциональности и модули системы. Такие группы — это и есть «Сервисы».

Причем, сервис может зависеть от модуля, и будет выполнен только при условии что модуль установлен у конечного клиента модуля. Так можно учесть установку на разных редакциях 1С-Битрикс, и создавать редакции тиражного решения в виде набора («бандла») своих модулей.

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

На практике не встречал решений на Marketplace с таким выбором.

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

Более подробно о создании мастера в документации от Битрикса.

# Среднестатистический мастер тиражного решения:

• Копирует файлы публичной части
  • Не забывая про многосайтовость — все ссылки на статических страницах и в настройках шаблонов адресов у комплексных компонентов должны начинаться с SITE_DIR
  • Заменяет в контенте части, задающиеся в настройках (названия, контактные данные, ID инфоблоков и т.п.)
  • Настраивает правила ЧПУ (/urlrewrite.php)
• Копирует файлы шаблона сайта, файлы цветовой схемы, выбирает шаблон в настройках сайта
• Импортирует инфоблоки с демо-данными из XML, настраивает инфоблоки (правами, настроки полей, списков и форм админки)
• Выставляет другие настройки, хранимые в БД, с помощью API Зависит от конкретного сайта, но как правило, это:
  • Типы меню
  • Типы и шаблоны почтовых сообщений
• Заполняет данные других модулей (веб-формы, блоги, форумы, рубрики подписки, группы пользователей — всё, что угодно)

# Публикация модуля

В личном кабинете Marketplace, есть в документации битрикса

# Выпуск обновлений

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

С обновлениями обычных модулей всё довольно просто:

• В них нельзя менять public и protected в API модулей — только добавлять новое (классы, метода, аргументы и прочее)
• Нельзя удалять компоненты, менять набор или типы данных для параметров компонентов, данных, передаваемых в шаблон компонента.

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

В тиражных решениях дополнительно нужно учитывать что:

• Нельзя изменять публичную часть вместе с обновлениями модуля через систему обновлений
• В типовой вариант сайта могли вноситься изменения в:
  • Шаблон сайта и шаблоны компонентов в нём
  • Разделы и страницы публичной части
  • Модели данных (инфоблоки, хайлоад блоки)

# Как можно обновлять тиражные решения?

Может потребоваться добавить новый раздел сайта или изменить существующие

• В процессе вносятся изменения в модели, настройки модулей в БД
• Перезаписываются изменененные файлы публичной части и шаблонов сайта

Конечно, при перезаписи файлов теряются все доработки, вносившиеся в файлы публичной части и шаблона сайта.

1. Для применения обновления мастер запускается повторно, перезаписывает публичную часть, настройки (свойства) инфоблоков на новую типовую версию.
2. Для применения обновления запускается отдельный мастер обновления, последовательно применяющий новые миграции для публичной части.
   • В долгосрочной перспективе мало отличается от варианта 1: кастомизированные файлы все-равно рано или поздно перезапишутся.
3. Как обновляется коробочная версия Битрикс-24 Раньше обновлялась по варианту 1 повторным запуском мастера.
   С некоторых пор обновляет публичную часть и шаблон вместе с обновлениями модулей Интранет и Экстранет, перезаписывя все ваши изменения в них.

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

# Создание среды для доработки тиражки

• Устанавливаем дистрибутив Битрикс в cp1251
• Во время установки на этапе выбора решения для установки ничего не выбираем, открывам в отдельной вкладке админку
• Клонируем модуль из git в папку /bitrix/modules/
• Устанавливаем модуль в админке
• Обновляем вкладку с установщиком битрикса, в списке решений появится наше — устанавливаем его

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

Симолические ссылки:

Откуда	Куда
/bitrix/modules/<модуль>/install/components/citrus	/bitrix/components/citrus	Компоненты копируются при установке модуля.
/bitrix/modules/<модуль>/install/wizards/citrus	/bitrix/wizards/citrus	Мастер копируется автоматом после выбора в списке мастеров
/bitrix/modules/<модуль>/install/wizards/citrus/<код мастера>/site/templates/<код шаблона>	/bitrix/templates/<код шаблона>	Шаблон сайта копируется в процессе работы мастера

В корне проекта инициализируем репозиторий git для контроля изменений в публичной части, по завершению доработки это поможет перенести изменения в файлы публичной части мастера (/bitrix/wizards/citrus/arealty/site/public/ru).

Все изменения в модули вносятся коммитами в git в отдельную ветку вида task_<номер задачи>,