Разработка конвертера размеров (RU/EU/US/UK) на 1С-Битрикс

Разработка конвертера размеров (RU/EU/US/UK) на 1С-Битрикс

Возвраты из-за неправильного размера — головная боль любого интернет-магазина одежды или обуви. Покупатель вводит свой US 8, получает неподходящий товар, пишет претензию. Мы разрабатываем конвертер размеров на 1С-Битрикс, который мгновенно переводит RU/EU/US/UK системы, снижая процент возвратов на 15–30% (опыт наших проектов). В отличие от статичной таблицы, конвертер решает конкретную задачу пользователя: «я знаю свой американский размер, скажите российский». Это разные инструменты с разными сценариями использования, хотя данные для обоих берутся из одного источника.

Сценарии использования конвертера

Сценарий 1: Конвертер на странице каталога или категории. Пользователь ещё не выбрал товар, хочет разобраться с размерной сеткой. Отдельная страница /razmer/ или блок в сайдбаре.

Сценарий 2: Конвертер в модальном окне на карточке товара. Прямо при выборе размера — удобнее всего, не уводит со страницы.

Сценарий 3: Inline-конвертер рядом с выбором торговых предложений. Компактный виджет «Не знаете свой размер? Введите US/EU:» рядом с кнопками ТП.

Как конвертер снижает возвраты?

Конвертер работает мгновенно, без перезагрузки страницы. Данные загружаются один раз при инициализации и обрабатываются на клиенте. Это исключает ошибки перевода и снижает когнитивную нагрузку на покупателя. В наших проектах внедрение конвертера уменьшало возвраты по причине «не подошёл размер» в среднем на 20%.

Хранение данных конвертера

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

-- Та же таблица, что для таблицы размеров
SELECT size_ru, size_eu, size_us_m, size_us_w, size_uk, foot_length_mm
FROM b_shoe_size_rows
WHERE chart_id = ?
ORDER BY foot_length_mm ASC;

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

Реализация конвертера: клиентская логика

Для UX конвертер должен работать мгновенно, без сетевых запросов. Данные загружаются один раз при инициализации страницы (или при открытии модального окна) и затем обрабатываются на JS:

// Данные прокидываются из PHP в JSON при загрузке страницы
const sizeData = <?= json_encode($arResult['SIZES'], JSON_UNESCAPED_UNICODE) ?>;

// Структура: [{size_ru: 40, size_eu: 40, size_us_m: 7, size_us_w: 8.5, size_uk: 6, ...}]

function convertSize(fromSystem, value, toSystem) {
    const numValue = parseFloat(value);
    const row = sizeData.find(r => {
        const fieldName = `size_${fromSystem}`;
        return parseFloat(r[fieldName]) === numValue;
    });
    if (!row) return null;
    return row[`size_${toSystem}`];
}

Форма конвертера:

<div class="size-converter">
    <select id="from-system">
        <option value="ru">RU</option>
        <option value="eu">EU</option>
        <option value="us_m">US (муж.)</option>
        <option value="us_w">US (жен.)</option>
        <option value="uk">UK</option>
    </select>
    <input type="text" id="size-input" placeholder="40">
    <button onclick="doConvert()">Конвертировать</button>

    <div id="conversion-result" hidden>
        <table class="result-table">
            <tr><th>RU</th><th>EU</th><th>US M</th><th>US W</th><th>UK</th></tr>
            <tr id="result-row"><!-- заполняется JS --></tr>
        </table>
    </div>
</div>

function doConvert() {
    const from  = document.getElementById('from-system').value;
    const value = document.getElementById('size-input').value.trim().replace(',', '.');

    const row = sizeData.find(r => String(r[`size_${from}`]) === value);
    if (!row) {
        document.getElementById('conversion-result').hidden = true;
        alert('Размер не найден. Проверьте введённое значение.');
        return;
    }

    document.getElementById('result-row').innerHTML = `
        <td>${row.size_ru}</td>
        <td>${row.size_eu}</td>
        <td>${row.size_us_m}</td>
        <td>${row.size_us_w}</td>
        <td>${row.size_uk}</td>
    `;
    document.getElementById('conversion-result').hidden = false;
}

Автодополнение ввода

При вводе в поле конвертера появляются подсказки с доступными значениями — это предотвращает ввод несуществующих размеров:

const input = document.getElementById('size-input');
input.addEventListener('input', function() {
    const from = document.getElementById('from-system').value;
    const query = this.value;
    const suggestions = sizeData
        .map(r => String(r[`size_${from}`]))
        .filter(v => v.startsWith(query));
    renderSuggestions(suggestions);
});

Что нужно учесть при интеграции с фильтром?

Расширенный кейс: конвертер интегрируется с умным фильтром Битрикс. Пользователь вводит свой US 8, конвертер переводит в RU 40–41, фильтр автоматически устанавливает значение «Размер: 40, 40.5, 41» и показывает только подходящие товары.

function applyToFilter(sizeRu) {
    const filterCheckboxes = document.querySelectorAll(`[data-filter-size="${sizeRu}"]`);
    filterCheckboxes.forEach(cb => {
        cb.checked = true;
        cb.dispatchEvent(new Event('change'));
    });
}

Это требует доработки шаблона умного фильтра и добавления data-атрибутов к чекбоксам размеров.

SEO конвертера

Отдельная страница конвертера может привлекать трафик по запросам «конвертер размеров обуви», «перевести US размер в российский». Для этого страница должна:

• Иметь семантическое название и описание
• Содержать статичную таблицу размеров (которую индексируют поисковики, в отличие от динамически сгенерированной через JS)
• Иметь структурированные данные Table в Schema.org

Процесс разработки

1. Анализ размерных сеток поставщиков и формирование единой таблицы соответствия.
2. Проектирование UX: выбор сценариев (модальное окно, inline, отдельная страница).
3. Реализация на PHP (инфоблоки, HL-блоки, компонент 2.0) и JS (конвертация, автодополнение).
4. Интеграция с 1С через CommerceML для автоматического обновления данных.
5. Тестирование на всех устройствах и браузерах.
6. Деплой и настройка кэширования (тегированное кэширование компонента).

Что входит в работу

• Анализ размерных сеток и подготовка данных
• Разработка компонента конвертера с автодополнением
• Интеграция с умным фильтром (опционально)
• SEO-страница конвертера со статической таблицей и Schema.org
• Интеграция с 1С: обмен данными через CommerceML
• Обучение сотрудников работе с конвертером
• Техническая поддержка в течение 2 недель

Сроки

Конвертер размеров — один из самых быстрых в разработке инструментов снижения возвратов. Небольшой объём работы, прямой измеримый эффект. Закажите разработку конвертера — свяжитесь с нами для консультации. Оценим ваш проект и предложим оптимальное решение.

Разработка и настройка модулей 1С-Битрикс

Главная ловушка Битрикса — init.php. Сунул туда обработчик OnBeforeIBlockElementUpdate, потом ещё один — через год файл на 2000 строк, и при каждом хите весь этот ком выполняется. Мы переносим бизнес-логику в полноценные модули с D7 ORM, собственными таблицами и административным интерфейсом. Модуль можно отключить, перенести на другой проект, покрыть тестами — с init.php ничего из этого не получится. Опыт команды — 10+ лет в Битрикс, сертифицированные специалисты, гарантия на код 6 месяцев. Закажите консультацию — расскажем, как перевести legacy-код в модульную архитектуру.

Почему init.php — худшее место для бизнес-логики?

Init.php не поддерживает автозагрузку классов, не имеет изолированного пространства имён, не поддаётся модульному тестированию и не отключается без правки самого файла. Каждый обработчик, написанный там, срабатывает на каждом запросе, даже если он не нужен. В модуле вы регистрируете обработчика через EventManager, и он выполняется только при наступлении события. Разница в производительности — до 3 раз при 10+ обработчиках.

Стандартные модули: типовые проблемы и решения

Информационные блоки. Архитектура ИБ — первое, что мы ревьюим на любом проекте. Классическая ошибка: один инфоблок каталога с 80 свойствами, из которых 30 — множественные. Таблица b_iblock_element_property раздувается до миллионов строк, CIBlockElement::GetList на фильтрации по трём свойствам уходит в полное сканирование. Переносим справочники в Highload-блоки, убираем множественные свойства где можно, проектируем структуру с прицелом на то, что каталог вырастет в 5 раз.

Интернет-магазин (sale). Бизнес-правила корзины — отдельная история. Настраиваем приоритеты скидок, чтобы две акции не дали 60% вместо 30%, подключаем платёжные обработчики, прописываем кастомную валидацию через OnSaleOrderBeforeSaved.

Поиск. Встроенный модуль search с морфологией работает до 10–15 тысяч элементов. Дальше — Elasticsearch. Настраиваем через API модуля поиска Битрикс, индексируем через CSearchFullText или кастомные индексаторы.

Highload-блоки для справочников, логов, пользовательских данных — вместо раздутых ИБ. Прямые запросы через Bitrix\Highloadblock\HighloadBlockTable, собственные таблицы вместо EAV-структуры стандартных инфоблоков. Миллион записей — без деградации.

Почтовые события. Настройка — не только шаблоны в b_event_message. Главное — SPF, DKIM, DMARC на DNS, иначе транзакционные письма летят в спам. Проверяем доставляемость, настраиваем bounce-обработку.

Проектирование инфоблоков для производительности

Используем Highload-блоки для справочных данных (цвета, размеры, производители), которые не участвуют в сложных выборках. Для торговых предложений — отдельный инфоблок с привязкой через IBLOCK_ELEMENT_PROPERTY. Включаем INDEX_PROPERTY для часто фильтруемых свойств. Кэширование тегированное: при изменении элемента сбрасывается только связанный кеш. Highload-блоки обрабатывают до 10 раз быстрее, чем инфоблоки с множественными свойствами, на объёмах от 100 000 записей.

Разработка кастомных модулей

Каждый модуль — по структуре /local/modules/vendor.modulename/:

• install/index.php — класс установки, создание таблиц через $DB->RunSQLBatch()
• lib/ — классы D7 ORM, наследники Bitrix\Main\ORM\Data\DataManager
• admin/ — административные страницы через CAdminList, CAdminForm
• include.php — автозагрузка, регистрация обработчиков через EventManager::getInstance()->registerEventHandler()
• REST API endpoints через \Bitrix\Rest\RestManager

Модуль регистрируется в системе, появляется в списке «Установленные решения», имеет свои настройки в /bitrix/admin/settings.php?mid=vendor.modulename. Его можно включать, отключать, обновлять через UpdateSystem или свой механизм миграций.

Примеры реализованных задач:

• Управление акциями — визуальный конструктор условий через CAdminCalendar, таймеры через агенты (CAgent::AddAgent), аналитика эффективности в связке с модулем sale
• Калькулятор стоимости — React-виджет на фронте, REST API в модуле, формулы хранятся в Highload-блоке
• Система бронирования — real-time календарь, блокировка через $DB->StartTransaction() / $DB->Commit() при одновременных запросах, синхронизация с channel manager через webhook

Компоненты и композитный кэш

Кастомизация компонентов — через result_modifier.php и component_epilog.php, не через правку template.php стандартного шаблона. Так ядро обновляется безболезненно.

Композитный кэш (технология «Композитный сайт») — сервер отдаёт готовый HTML, минуя PHP-роутинг. Динамические зоны (корзина, авторизация) подгружаются через CBitrixComponent::setFrameMode(true) и AJAX. TTFB падает до 30–50 мс. Но есть нюансы: не все компоненты совместимы, $APPLICATION->ShowPanel() ломает композит, нужна аккуратная разметка <div id="bx-composite-...">.

Маркетплейс: аудит перед установкой

Перед установкой модуля с маркетплейса — обязательный аудит. Проверяем: SQL-запросы без подготовленных выражений (привет, SQL-инъекции), прямое обращение к $_REQUEST без фильтрации, использование устаревшего API старого ядра вместо D7, конфликты с модулем композитного кэширования. Модуль без обновлений больше года и с парой десятков установок — скорее всего, проблема на ближайшем обновлении PHP. Типичный случай: модуль вызывает CIBlockElement::GetList с несброшенным кешем — сайт падает при 5000 элементов.

Миграция на D7

При обновлении PHP или переходе на новую редакцию — рефакторинг устаревших вызовов:

• CIBlockElement::GetList() → Bitrix\Iblock\Elements\ElementTable::getList()
• CSaleOrder::GetList() → Bitrix\Sale\Order::getList()
• CModule::IncludeModule() → Bitrix\Main\Loader::includeModule() Тестирование на staging, откат через git при проблемах.

Согласно официальной документации 1С-Битрикс, D7 ORM является рекомендуемым средством для работы с данными, обеспечивая безопасность типов и автогенерацию запросов.

Сравнение подходов: Init.php vs Модуль

Стоимость и состав разработки модулей

Что входит в разработку модуля?

• Техническое задание и архитектурная схема
• Код с соблюдением PSR-4 и код-стайла Битрикс
• Unit-тесты (PHPUnit) на бизнес-логику
• Интеграционные тесты на события и REST API
• Документация по установке, настройке и API
• Передача доступов к репозиторию и документации
• Обучение администраторов работе с модулем
• Гарантийная поддержка 6 месяцев

Ориентировочные сроки и сложность:

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

Тестирование модулей

Unit-тесты через PHPUnit покрывают бизнес-логику: расчёт скидок, валидацию, формирование документов. Моки для Bitrix\Main\Application::getConnection() позволяют тестам не зависеть от БД. Интеграционные тесты проверяют обработчики событий на реальной базе — OnAfterIBlockElementAdd, OnSaleOrderSaved и другие. REST API endpoints тестируем через curl или PHPUnit HTTP-клиент. Критично для модулей, работающих с b_sale_order, b_catalog_price — где ошибка стоит денег.

Совместимость проверяется на PHP 7.4, 8.0, 8.1, 8.2 и редакциях: Стандарт, Малый бизнес, Бизнес. Проверяем конфликты с популярными модулями маркетплейса — они любят перехватывать те же события. Нагрузочное тестирование: замеры на 10K, 100K, 1M записей, профилирование через Xdebug на предмет утечек памяти и N+1 запросов.

Примеры из практики

Модуль акций для сети электроники. Штатные скидки модуля sale не покрывали сценарии «2+1», подарок при покупке от суммы, комбинированные условия. Собрали визуальный конструктор: маркетолог создаёт правила через drag-and-drop, без тикетов в разработку. Календарь акций, автодеактивация через агенты, аналитика в привязке к b_sale_order — конверсия, средний чек, количество применений. Время запуска новой акции упало с двух дней до получаса.

Калькулятор для строителей. Параметры (площадь, материалы, этажность) → формула → предварительная смета → заявка в CRM через CRest::call('crm.lead.add'). Региональные коэффициенты и сезонные наценки — из Highload-блока, цены материалов — из обмена с 1С. Количество целевых заявок выросло на треть: клиенты видят разбивку по статьям до звонка менеджеру.

Бронирование для сети отелей. Real-time доступность через AJAX-запросы к кастомной таблице vendor_booking_slots, расчёт тарифов по сезону, синхронизация с Booking.com через channel manager API. Блокировка номера при одновременном бронировании — через SELECT ... FOR UPDATE в транзакции. Таймзоны обрабатываются через \DateTimeZone — гость из Владивостока и менеджер из Москвы видят одну картину.

Оценим проект за 1 день. Пишите — расскажем, что входит в разработку под ключ. Свяжитесь с нами для консультации по вашему проекту. Закажите разработку модуля под ключ — получите готовое решение с документацией и поддержкой.