Кастомизация формы оформления заказа

Компонент sale.order.ajax закрывает базовые сценарии оформления, но реальный магазин почти всегда требует своих полей, блоков и логики. Кастомизировать чекаут в 1С-Битрикс нужно копией шаблона, а не правкой ядра — тогда доработки переживут обновление платформы.

Как устроена форма оформления заказа

Форма чекаута в 1С-Битрикс собирается комплексным компонентом bitrix:sale.order.ajax. Он подключается на странице /personal/order/make/ и работает по AJAX: шаги (корзина, регион, свойства, доставка, оплата) перерисовываются без полной перезагрузки. Важно понимать разделение ответственности:

• Компонент (component.php в ядре) готовит массив $arResult: корзину, свойства заказа, службы доставки и платёжные системы. Его не трогаем.
• Шаблон (template.php) — HTML-разметка и вывод данных. Здесь и живёт визуальная кастомизация.
• result_modifier.php — код, который выполняется до шаблона и позволяет дополнить или преобразовать $arResult.
• JS-ядро — объект BX.Sale.OrderAjaxComponent, который управляет отправкой формы и перерисовкой шагов.

Понимание этой схемы задаёт единственно верное правило: править нужно копию шаблона и его modifier, а не файлы в /bitrix/components/bitrix/.

Копируем шаблон в свой namespace

Прежде чем менять хоть строчку, вынесите шаблон в собственное пространство имён. Штатный шаблон .default лежит в ядре и будет перезаписан при обновлении, поэтому копируем его в шаблон сайта:

Из /bitrix/components/bitrix/sale.order.ajax/templates/.default/ копируем каталог в /local/templates/ВАШ_ШАБЛОН/components/bitrix/sale.order.ajax/mytemplate/. Затем в вызове компонента на странице make.php указываем новое имя шаблона.

После копирования проверьте, что подтянулись все зависимости шаблона: подшаблоны шагов (confirm.php, вложенные template.php для блоков доставки и оплаты), а также style.css и script.js. Битрикс ищет их относительно каталога шаблона, поэтому копируем директорию целиком, а не один файл.

Правим template.php и result_modifier

Основную вёрстку меняем в template.php. Шаблон построен на JS-шаблонизаторе: часть блоков рендерится PHP при первой загрузке, а при AJAX-перерисовке те же участки собираются в script.js. Поэтому изменение только PHP-разметки часто ломает шаг после первой же перерисовки — правки нужно синхронно вносить и в JS-рендер соответствующего блока.

Данные, которых не хватает в $arResult, добавляйте через result_modifier.php, а не запросами прямо в шаблоне:

• подтянуть описание к службе доставки из инфоблока;
• сгруппировать свойства заказа в удобные для вёрстки блоки;
• заранее вычислить флаги (например, «показывать поле ИНН только для юрлиц»).

Свои поля и блоки в форме

Есть два принципиально разных способа добавить поле, и их важно не путать.

Если поле должно сохраняться в заказе — создавайте свойство заказа в админке, а в шаблоне лишь управляйте его выводом. Тогда значение автоматически запишется в заказ, отобразится в детальной и уйдёт в обмен с 1С. Свойства доступны в шаблоне через массив $arResult['JS_DATA']['ORDER_PROP']['properties'], а привязка к персоне — через группы свойств.

Кастомные визуальные блоки (баннер акции, блок «нужен чек?», согласие на обработку данных) размещайте прямо в разметке нужного шага. Чтобы значение чекбокса-согласия ушло в заказ, оберните его в отдельное свойство типа Y/N — иначе оно не сохранится.

JS-события BX.Sale.OrderAjaxComponent

Динамику чекаута контролирует объект BX.Sale.OrderAjaxComponent. Он публикует события, на которые можно навесить свою логику без правки ядра. Подписка выполняется через BX.addCustomEvent:

• onAjaxSuccess — форма перерисована после ответа сервера; момент, чтобы повесить обработчики на свои поля и инициализировать плагины (маски телефона, автодополнение адреса).
• onAjaxFailure — ошибка запроса; здесь показывают своё сообщение.
• onSaveOrderSuccess, onSaveOrderFailure — результат сохранения заказа; удобно для аналитики и пикселей.

Ключевой нюанс: после каждой AJAX-перерисовки DOM пересобирается, поэтому обработчики, навешенные напрямую на элементы при загрузке страницы, теряются. Инициализируйте их заново в onAjaxSuccess либо используйте делегирование событий от неизменного контейнера. Отправку данных можно инициировать методом sendRequest() компонента, а прочитать текущее состояние — из его свойства result.

Риски при обновлении платформы

Главная угроза кастомизации чекаута — разъезжание вашей копии шаблона и обновлённого ядра. Битрикс регулярно дорабатывает модуль sale: меняется структура $arResult, JS-рендер, названия блоков. Ваш замороженный шаблон этих изменений не получает.

• Функциональный разрыв: новая версия компонента отдаёт данные иначе, а старый шаблон их не выводит — ломается шаг доставки или оплаты.
• JS-конфликты: обновлённый BX.Sale.OrderAjaxComponent меняет сигнатуры, ваш script.js с копией шаблонизатора начинает работать некорректно.
• Тихая деградация: форма визуально работает, но перестаёт сохранять кастомное свойство.

Минимизируйте объём правок в самом шаблоне: чем больше логики вынесено в result_modifier.php и внешние JS-обработчики через события, тем проще потом пересобрать шаблон на новой версии.

Итог

Безопасная кастомизация чекаута в 1С-Битрикс строится на трёх опорах: копия шаблона sale.order.ajax в /local/, вынос логики в result_modifier.php и подписка на события BX.Sale.OrderAjaxComponent вместо правки ядра. Данные, которые должны попасть в заказ и 1С, оформляйте свойствами заказа, а не самодельными полями. И держите шаблон под контролем версий, чтобы обновления платформы не превращались в сюрприз.

Мы в B2Bsite проектируем и дорабатываем чекаут так, чтобы он оставался обновляемым: аккуратная кастомизация, синхронизация со свойствами и обменом с 1С, тесты перед деплоем. Если форма заказа требует нестандартной логики или пора привести доработки в порядок — поможем спроектировать и внедрить решение без потери обновляемости.