Xml id битрикс что это
Настройка ЧПУ для умного фильтра 1С Битрикс
Давайте рассмотрим одну из часто-встречающихся задач при создании интернет-магазина на 1С Битрикс, а именно настройку ЧПУ адресов каталога и умного фильтра. Дело в том, что по умолчанию каталог и фильтр работают без ЧПУ используя параметры передаваемые в адресной строке браузера (GET параметры) и URL адреса страницы выглядят трудно-читаемыми и не запоминающимися.
Для чего нужен ЧПУ
Термин ЧПУ в веб-разработке, означает ЧеловекоПонятный Урл, от английского friendly url (дружелюбный урл). Обычно он представляет собой краткий, хорошо читаемый адрес страницы, обычно транслитерированное (т.е. написанное на «латинице») слово или словосочетание, которое легко запомнить человеку. Кроме того, такой адрес отражает значение или содержимое страницы, например так:
Как видите такой URL легко воспринять и даже запомнить. Но для чего ещё нужно внедрять ЧПУ? Дело в том, что наличие ЧПУ адресов, не только страниц, но и различных ресурсов (картинок, видео) является требованием поисковых систем Яндекс, Google и д.р. Это своего рода один из показателей качества вашего сайта. Такие страницы быстрее проходят индексирование и попадают в поисковую выдачу.
Настройка адресов для инфоблока
В первую очередь нам необходимо перейти в настройки информационного блока каталога (или другого если речь не идёт о ЧПУ для каталога и фильтра) на вкладке «Инфоблок» есть 3 свойства, задающие своего рода шаблон на основе которого система построит URL адрес страницы:
Эти шаблоны — первая часть настройки ЧПУ, далее следует позаботиться о наличие читаемого кода для свойств инфоблока и их значений. Для этого перейдём на вкладку «Свойства» и рассмотрим несколько представленных в каталоге свойств, материал и цвет:
Каждое свойство инфоблока имеет параметр «Код», это мнемонический код свойства, тот самый который будет позже поставлен в URL адрес, когда мы захотим отфильтровать каталог по этому свойству. И чтобы получившийся в итоге ЧПУ отвечал критериям «понятности», код свойства должен быть читаемым и понятным для человека, в данном случае «материал» и «цвет».
Так же не стоит забывать, что для свойств типа «список» можно настроить понятный код значения свойства.
В данном случае, в качестве кода значения свойства, выступает атрибут XML_ID именно его система подставит в URL адрес, когда мы захотим отфильтровать каталог одежды по свойству «цвет». Если, оставить эти поля пустыми, при сохранении настроек информационного блока, битрикс сгенерирует длинную хеш-строку и подставит её в качестве XML_ID
В данном примере вся строка XML_ID розового цвета выглядит так: 4ed329daf7a1bd6ec22074f850e50be1 — не очень читабельно, не так ли? К сожалению 1С Битрикс не имеет штатного функционала позволяющего автоматически транслитерировать значения свойств и читаемый XML_ID.
Автоматическая транслитерация XML_ID
Чтобы не переводить название цветов вручную каждый раз когда мы добавляем вариант значения свойства цвет, можно подвесить свой обработчик на событие обновления этого свойства. В моём случае свойство цвет является «списком» поэтому нам следует выбрать обработчик OnBeforeIBlockPropertyUpdate (ссылка на документацию). Т.е. при обновлении нам нужно перебрать значения списка, выбрать те у которых не заполнен XML_ID (чтобы не затронуть XML_ID которые возможно были заданы вручную), затем транлитерировать значение списка (название цветов на русском языке) и записать в XML_ID значения. Поехали:
Этот код необходимо добавить в файл init.php. Теперь если заполнить значения цветов и не указать XML_ID вот так:
И сохранить настройки свойства а затем и инфоблока, отработает наше событие и недостающие XML_ID будут заполнены согласно нашему обработчику.
Подобным образом вы можете обработать другие типы свойств.
Настройка компонента
Перейдём к настройке компонента «Каталог товаров». Проще всего сделать это из публичной части перейдя в режим правки. В окне настроек компонента находим блок «Управление адресами страниц» и задаём следующие настройки:
Заключение
На самом деле стандартные страницы фильтра можно значительно улучшить с точки зрения SEO оптимизации, например вывести уникальные мета-данные страницы для каждого урла, задать уникальный заголовок h1, вывести SEO тексты. Чтобы внедрить все эти фишки, читайте другую статью по тонкой настройке фильтра.
О формате XML-файла импорта в инфоблоки Битрикса
В предыдущей статье на тему переноса контента в Битрикс мы рассказали об основных задачах, которые необходимо решать для массового импорта данных. Также отметили, почему XML файл посчитан нашей студией наиболее пригодным для осуществления импорта данных в Битрикс.
В этой статье мы вкратце осветим тему построения XML структуры файла импорта.
Что должен содержать XML файл
Укрупнённо XML файл импорта-экспорта имеет следующую структуру:
Предназначен для описания, ну скажем так, схемы инфоблока (примерно как схема БД), т. е. описывает поля и свойства, которые у инфоблока имеются (или должны иметься). Кстати, с точки зрения импорта, тем более если мы импортируем в уже существующий инфоблок, это очень важный раздел, так как в случае его отсутствия Битрикс любезно допишет в инфоблок свойства, которые, как он считает, должны быть там по умолчанию — Цена, ШтрихКодТовара, Изгтовитель, Вес и еще много подобных. Удалять их придётся вручную.
Также этот раздел может содержать разделы (папки), к которым можно привязывать элементы. Если указанных в файле разделов нет, они будут созданы.
Предполагает наличие дополнительной информации об инфоблоке, такой как буквенно-цифровой код инфоблока (например, ‘news’), код сортировки инфоблока в списке, флаг разрешения индексации элементов и прочие.
Идентификация
В Битриксе для инфоблоков и их содержимого существует понятие „внешних“ кодов (XML_ID или EXTERNAL_ID), которые нужны для связи с внешним миром. То есть если для целей импорта надо каким-то образом идентифицировать инфоблок, его раздел, или его элемент, надо применять такой внешний код. В интернете этот вопрос поднимался много раз (здесь, здесь, здесь, и далее по списку google).
Соответственно, всё, что содержит в себе файл импорта, будет записано в тот инфоблок, который:
Импортируемые файлы
Файлы, которые должны быть импортированы в инфоблок как свойства элементов, при импорте должны лежать где-то таким образом, чтобы в файле импорта до них был прописан путь относительно файла импорта. На примере картинки «подробно» (DETAIL_PICTURE):
тогда должно быть расположение файлов:
Свойства элементов
так и иметь более сложную структуру, как, например:
множественные свойства имеют такую форму:
А так выглядит структура некоторых свойств, значения которых, по логике Битрикса, не должны быть описаны прямым образом в xml структуре, но должны быть представлены в виде сериализованных данных:
Таким образом, при формировании файла импорта необходимо понимать, для какого именно свойства предназначены данные, и уже исходя из этого генерировать нужную структуру.
Ошибки импорта
Если во время импорта произойдут какие-либо ошибки, Битрикс обязательно об этом сообщит. На этом любезности и удобства заканчиваются, так как не будет не только указаний о том, какие ошибки произошли, но также умалчивается, при импорте каких именно элементов они случились (представьте ситуацию — импорт на 4 тысячи элементов, и 2 ошибки в конце, видимо, предлагается беглым осмотром инфоблока в админке установить, что не импортировалось). В данном случае реальный способ выявить ошибочные — провести экспорт из инфоблока и сопоставить фактически попавшие в инфоблок элементы с исходным файлом импорта.
Ошибки из-за ЧПУ кодов
Как мы уже отмечали в предыдущей статье, Битрикс не генерирует ЧПУ коды во время импорта (даже если в настройках полей инфоблока установлена опция „Транслитерировать из названия при добавлении элемента.“ — вероятно, по мнению Битрикса, на импорт через XML это не распространяется). Соответственно, если кроме этого стоит галочка обязательности кода, то если импортировать элемент без кода, это вызовет ошибку, а если галка обязательности не указана, то проимпортируется с пустым кодом. Если код вам нужен, то оба сценария вас не устраивают. Технический момент: если вы импортируете в инфоблок, где уже есть элементы, необходимо позаботиться о том, чтобы ЧПУ коды импортируемых элементов не дублировали уже имеющиеся.
Ошибки из-за файлов
Если импортируются элементы с изображениями, недоступность файла изображения по указанному пути также вызывает ошибку. Поэтому в идеале после подготовки пакета файлов перед импортом следует проверять реальную физическую доступность всех файлов, указанных в xml-файле импорта.
Ошибки формата
XML файл импорта должен иметь корректную структуру, в противном случае произойдет либо ошибка импорта элемента целиком, либо не будет импортировано конкретное свойство. Оба сценария нас не устраивают. Если есть сомнения по вопросу формата, всегда можно вручную наполнить инфоблок данными, провести экспорт, изучить структуру полученного файла.
Обязательные данные
Разумеется, общим правилом также должно быть наличие данных для всех полей и свойств инфоблока, которые помечены как обязательные.
Бэкап перед импортом?
Во избежание проблем, тем более, если нет уверенности, что сформированный вами пакет импорта не приведёт к непредсказуемым результатам, сделайте архивную копию данных перед началом импорта. Идеальным подходом (в экосистеме Битрикса) делать это всегда.
Что нужно знать программисту про интеграцию сайта и 1С
Нельзя просто взять и интегрировать сайт с 1С. (с) Народное творчество.
Цель написания поста – изложить всю информацию по теме человеческим языком.
Интеграция сайта на 1С-Битрикс: Управление сайтом и 1С — неисчерпаемый источник вопросов и проблем. На сайте идей для Битрикс в соответствующем разделе 16 страниц, на форуме про это больше 23 000 сообщений. В форме обращения в техподдержку Битрикса есть даже отдельный тип заявки «Обмен с 1С».
Считается, что интеграция 1С и сайта на Битриксе должна работать из коробки. Самые простые функции действительно можно запустить за час-два. А вот на доработку обмена можно потратить и 10, и 100 часов.
Доработка обмена сайта и 1С — это уже магия уровня «эксперт», пугает даже бородатого опытного разработчика. В этой статье мы поговорим о том, как происходит обмен данными между этими двумя монстрами и как можно расширять возможности этого обмена. Статья содержит множество технических деталей обмена и будет полезна в основном программистам, которые хотят разобраться в предмете.
В данной статье будет рассмотрена общая теория обмена между двумя IT-системами и два стандартных обмена между 1С и сайтом на 1С-Битрикс: обмен товарами и обмен справочниками.
Немного теории
Интеграция — обмен информацией между двумя IT-системами. Иногда называют просто обмен. Определяется форматом данных, протоколом (стандартом) передачи данных, алгоритмом работы
Формат = как выглядят данные (например, XML, YML, JSON, CSV).
Протокол = как данные оказываются в другом месте (например, HTTP, SIP, SMTP, FTP).
Алгоритм = что при этом происходит. Представляется блок-схемой или диаграммой UML Activity.
обмен товарами между самописной учетной системой и сайтом (протокол FTP, формат CSV);
парсинг курсов валюты с сайта ЦБ РФ (протокол HTTP, формат XML);
интеграция сайта с Яндекс.Маркет (протокол HTTP, формат YML).
Процедуру обмена можно разделить на 3 части:
Экспорт данных из системы А в требуемый формат
Импорт данных требуемого формата в систему Б.
Часто весь обмен называют «импорт» («загрузка») и «экспорт» («выгрузка»). Это не ошибка, по такой формулировкой говорящий показывает, точка зрения какой системы ему ближе. То, что для 1С экспорт товаров, для Битрикса импорт. В дальнейшем тексте статьи мы не будем использовать эти понятия, чтобы не порождать двусмысленности.
Резюме
Интеграция — обмен данными между двумя системами.
Формат — как выглядят данные.
Протокол — как передаются данные.
Стандартные возможности обмена 1С и Битрикса
«Из коробки» (без доработок программиста) работают 4 типа обмена:
товары из 1С на сайт (тип «catalog»);
справочники из 1С на сайт (тип «reference»);
пользователей/контрагентов из 1С на сайт (тип «sale»);
Протокол
Все взаимодействия между 1С и Битриксом проводятся по HTTP, синхронно. Т.о. 1С подобна браузеру, она «открывает» специальную страницу, отправляет данные (методами POST и GET) и получает текстовый ответ. Есть даже способ имитировать выгрузку из 1С браузером (и мы часто используем этот трюк во время разработки и отладки). Подробнее про отладку мы рассказали в предыдущей статье «Типовые ошибки интеграции между 1С и 1С-Битрикс».
В терминах сетевых взаимодействий 1С — клиент, а сайт — сервер. Обращения всегда инициируются на стороне 1С. В 1С есть настройки адреса сайта, сайт про 1С не знает ничего.
Протокол синхронный. 1С отправляет следующий запрос на сайт только после получения ответа на предыдущий (или получения ошибки таймаута).
Формат
Данные передаются в двух форматах.
Первый формат — текстовый для ответов сайта на запросы из 1С. Сайт выводит в первой строке ответа «success», если завершил некую процедуру, «progress», если продолжает ее выполнять и «error» или «failure», если была ошибка. В последующих строках могут быть дополнительные данные (зависит от каждого конкретного запроса).
Алгоритм
Подготовка к обмену
Выше мы уже сказали, что протокол обмена — синхронный HTTP. Все перечисленные типы обмена подразумевают выполнение нескольких запросов (шагов обмена) друг за другом. Первые два шага одинаковы для любого типа обмена, различия начинаются дальше
BITRIX обмен заказами, товары криво попадают в заказ из 1С?
UDP1. проблема заключается в том, что на сайте 2 каталога товаров для разных сайтов. Каталоги используют одинаковый XML_ID товара.
в файле \bitrix\modules\sale\general\order_loader.php
выбирает по XML_ID без привязки к IBLOCK_ID, вот и получается такая хрень, несколько записей товара из разных IBLOCK_ID.
там же чуть ниже и наш 1C_Exchange в CATALOG_XML_ID
Решить можно тупо задав IBLOCK_ID в getlist() но такая штука будет работать до первого обновления.
или сделать чуть лучше перенести компонент bitrix:sale.export.1c в local и там изменить ему класс
и потом расширить класс CSaleOrderLoader который находится здесь /bitrix/modules/sale/general/order_loader.php
Подскажите в чем может быть проблема.
обмен заказами с 1С типовой.
Сайт формирует заказ >> 1С забирает этот заказ к себе >> Наполняет этот заказ новыми позициями >> 1С отправляет этот заказ на сайт
и вот что получается, некоторые товары не определяются.
Кривой товар добавленный из 1С, на месте [Внешний код каталога] почему-то логин пользователя 1С на сайте, хотя должен быть идентификатор каталога товаров (в XML заполнен правильно и в свойствах тоже правильно)
Полукривой товар добавленный из 1С (но он хотя бы определился как товар каталога)
а вот этот товар добавленный на сайте, у него все поля заполнены как нужно
Вот что передаёт 1С в XML
это товар который кривой, всё вроде норм в XML, сайт его не понимает.
Вот в этом же заказе код нормального товара, который был добавлен на стороне сайта
вот что происходит в БД таблица b_sale_basket
в таблице b_sale_basket_props товары которые добавлены из 1С информация отсутствует, только те что были добавлены на сайте
в чем может быть проблема? типовой обмен не трогался, работает из коробки
Миграции базы данных в 1С-Битрикс: быстро, правильно, надежно
Всё, всё, шо нажил непосильным трудом, всё же погибло!
Три магнитофона, три кинокамеры заграничных, три портсигара отечественных, куртка замшевая… Три. Куртки.
И они ещё борются за почётное звание «дома высокой культуры быта», а.
(с) Иван Васильевич меняет профессию
Если Вы разрабатываете проекты на 1С-Битрикс с привлечением двух и более программистов, то Вам сюда.
ИНТЕРВОЛГА делится с сообществом веб-разработчиков своим крутым инструментом для АВТОМАТИЧЕСКОЙ миграции БД в 1С-Битрикс.
При использовании нашего модуля, время на выполнение релиза и перенос изменения БД, сокращается с нескольких часов до 10-20 минут (при отсутствии конфликтов).
Поддерживаемые сущности
Среди огромного разнообразия данных в 1С-Битрикс: Управление Сайтом для первого раза мы выбрали следующие сущности.
Группы пользователей (сущность group )
Типы почтовых событий (сущность eventtype )
Почтовые события (сущность event )
Языки (сущность language )
Культура (сущность culture )
Сайты (сущность site )
Правила подключения шаблонов сайтов (сущность sitetemplate )
UF-поля (сущность field )
Варианты UF-списков (сущность fieldenum )
В модуле highloadblock :
ХЛБ (сущность highloadblock )
Поля ХЛБ (сущность field )
Варианты списков полей ХЛБ (сущность fieldenum )
Типы цен (сущность pricetype )
Типы плательщиков (сущность persontype )
Группы свойств заказа (сущность propertygroup )
Свойства заказов (сущность property )
Варианты списков свойств заказов (сущность propertyvariant )
Типы ИБ (сущность type )
ИБ (сущность iblock )
Свойства ИБ (сущность property )
Варианты свойств ИБ (сущность enum )
Поля разделов (сущность field )
Варианты полей разделов (сущность fieldenum )
Формы редактирования элементов и разделов ИБ (сущность form )
Уникальные ID для миграции
Для сопоставления записей между несколькими БД нужно выбрать уникальный ID. Родные числовые ID не подходят на эту роль — ими нельзя управлять и они могут различаться в разных БД.
Аналогичная проблема есть при обмене товарами и заказами между сайтом и 1С. Там она решается с помощью уникального внешнего кода — XML_ID. Вот только не у всех данных в БУС предусмотрено это поле. А у тех, что есть, оно не всегда уникальное. Пришлось нам сделать “надстройку” над системным полем XML ID. В таблице ниже описаны все сущности с их XML ID миграции.
Сущность | XML ID миграции |
---|---|
Группа пользователей | STRING_ID |
Тип почтового события | LID + EVENT_NAME |
Почтовый шаблон | md5(EMAIL_FROM+EMAIL_TO+EVENT_NAME+сайты) |
Язык | LID |
Культура | NAME |
Сайт | LID |
Настройка шаблона сайта | SITE_ID+TEMPLATE+md5(CONDITION) |
UF-поле | md5(ENTITY_ID+FIELD_NAME) |
Вариант списка UF-поля | XML_ID |
highload-блок | TABLE_NAME |
Поле highload-блока | md5(highload-блок+FIELD_NAME) |
Вариант списка поля highload-блока | XML_ID |
Тип цены | XML_ID |
Тип плательщика | md5(NAME+сайты) |
Группа свойств заказа | md5(NAME+Тип плательщика) |
Свойство заказа | md5(CODE+Тип плательщика) |
Вариант свойства заказа | md5(VALUE+Свойство заказа) |
Тип инфоблока | ID |
Инфоблок | XML_ID |
Свойство инфоблока | Инфоблок+XML_ID |
Вариант свойства инфоблока | Инфоблок+XML_ID |
Право на инфоблок | md5(Инфоблок+Группа) |
Форма редактирования | Инфоблок+несколько полей формы |
Поле раздела инфоблока | md5(Инфоблок+FIELD_NAME) |
Вариант списка поля раздела инфоблока | XML_ID |
Конфигурирование модуля
Узел | Родительский узел | Описание |
---|---|---|
— | Корневой | |
Настройки миграции модуля | ||
Название модуля | ||
Сущность для миграции | ||
Название сущности | ||
Мигрируемые настройки | ||
Регулярное выражение для исключения настроек из миграций |
Команды модуля
Для устранения проблем с таймаутом сервера (и чтобы придать тёплую ламповую атмосферу) вся работа с модулем после установки вынесена в командную строку. Точка входа: /intervolga.migrato/tools/run.php (в примерах для краткости будет обозначена как run.php ).
Интерфейс модуля в командной строке
Синтаксис простой:
$ php run.php команда [опции]
Служебные команды (для разработчиков новых сущностей):
Проверка XML ID (команда validate)
Модуль читает config.xml и проверяет, чтобы у всех экземпляров сущностей были заданы корректные XML ID. Команда ничего не изменяет в БД. Критерии корректного XML ID:
Автоматическое исправление ошибок XML ID (команда autofix)
Экспорт в *.xml-файлы (команда export)
Импорт из *.xml-файлов (команда import)
Вывод логов предыдущей команды (команда log)
Генерация демо-контента (команда для разработчиков generate)
Помните, трава раньше была зеленее, мороженое вкуснее а модуль DEFA Tools был бесплатным? Его генератор демо-контента мы воспроизводить, конечно, не стали, но добавить по 2 записи в каждую сущности команда generate может. Команда полезна для разработчиков новых сущностей.
Тестирование модуля (команда для разработчиков unittest)
Вторая команда, полезная для разработчиков (и тестировщиков). Исполняется сценарий.
Если все сущности работают правильно, diff будет пустым. Если же нет — это значит, что в коде сущности есть ошибка и она импортируется в базу неправильно.
Формат XML файлов
Синтаксис XML-файлов миграции настроек модулей
Узел | Родительский узел | Описание |
---|---|---|
— | Родительский узел | |
Настройка | ||
Название настройки | ||
Значение настройки | ||
Сайт, для которого задано значение |
Синтаксис XML-файлов миграции данных
Узел | Родительский узел | Описание |
---|---|---|
— | Родительский узел. Атрибут deleted говорит, что данные были удалены | |
XML ID данных | ||
Узел зависимости | ||
Узел ссылки | ||
Узел простого поля | Название поля | |
Значение поля |
Как пользоваться модулем
Чтобы начать использовать модуль необходимо на боевом сайте создать оригинальный слепок БД:
Чтобы подготовить миграцию на песочнице devX после окончания работы над задачей:
Выполнить миграцию (релиз) на боевом сайте:
Использование XML ID вместо ID в коде
Пытливый читатель-программист может задать вопрос: как же теперь писать код, если использовать ID — плохо, а XML ID миграции не всегда совпадает с XML ID сущности?
Модуль предоставляет API для получения ID по XML ID:
\Intervolga\Migrato\Data\BaseData::getPublicId($xmlId)
Метод использует кеширование, так что о производительности не стоит беспокоиться.
Если вы используете константы для обращения к сущностям по ID, то вам только и нужно — сделать следующую замену.
Было
Стало
А вот второе изменение принять будет не так просто. Визуальный редактор БУСа при работе с компонентами генерирует код, в котором явно фигурируют “магические” неуникальные числовые ID.
Вот за такое хочется Битрикс от души поругать. Генерация кода зашита очень глубоко и кастомизировать её нет никакой возможности. Мы не стали придумывать хитрых способов подмены такого кода и просто ввели правило — визуальным редактором для редактирования компонентов не пользуемся. Программист один раз настраивает компонент, потом заменяет ID на XML ID миграции и никаких няш-мяш. Если знаете способ лучше — расскажите в комментариях, с радостью примем на вооружение.
Выполнение примера из других модулей
И, напоследок, выполнение общего примера нашим модулем. Сразу после установки проверили все записи на наличие внешних ключей и исправили ошибки:
После того, как каждый программист выполнит свою задачу на своем сайте, он делает экспорт. Так как изменения были произведены только в ИБ модуле, то и экспортировать другие модули нет смысла (Настройка config файла).
После программист делает коммит экспортируемых файлов, и перед тем как вытолкнуть файлы на удаленный репозиторий необходимо проверить, может другой программист выполнил задание быстрее (git pull).
На этом шаге, возможна ситуация возникновения конфликта. Что же, тут есть 2 пути, смотря как Вам удобней работать. Если у вас git на серверах разработки, при конфликте появится такое предупреждение:
Открываете файл, например с помощью vim (vi local/migato/iblock/type/. ) и выбираете, кто из программистов не врет.
После этого индексируете файлы и коммитете.
Есть еще второй путь, если у вас гит только на локальной машине, и синхронизируете все файлы с помощью гита, но на локальной машине. На примере показано возникновение конфликта в IDE PHPStorm.
Как только все конфликты разрешены, программист должен вытолкнуть изменения на сервер.
После того, как все программисты вытолкнули свои изменения, версия базы данных в системе управления версий стабилизируется. Это значит, что наступило время делать релиз. После которого, чтобы обновить любой сайт (будь то сайт для разработки или prod), достаточно трех глобальный вещей:
В результате, каждый сайт имеет актуальную версию базы данных со всеми изменениями. Будь то удаление, создание или изменение записи с конфликтами или без, наш модуль превосходно справился с поставленными задачами.
Вместо выводов
Инструмент для миграции изменений БД жизненно необходим при ответственной командной работе над проектами. До сегодняшнего дня эта задача в мире 1С-Битрикс решалась очень плохо.
Мы же разработали промышленное решение этой задачи и отдаем его бесплатно всем желающим. Пользуйтесь, предлагайте улучшения, участвуйте в развитии, мы будем рады. Чтобы получить ссылку на установку модуля миграций для Битрикс, “поделитесь” статьей в соцсетях и укажите ссылку в форму под статьей. Ссылка на репозиторий с документацией придет вам на почту.