Розробка кастомного кошика 1С-Бітрікс
Стандартний компонент bitrix:sale.basket.basket закриває базові задачі, але ламається під нестандартні вимоги бізнесу: немає збереження кошика між сесіями без авторизації, неможливо додати кастомні поля до позиції (наприклад, гравірування або колір упаковки), а верстка компонента — це складний шаблон із застарілою структурою. У таких випадках кошик розробляють з нуля або глибоко переробляють стандартний компонент.
Як влаштований кошик у Бітрікс
Кошик зберігається у таблиці b_sale_basket. Кожна позиція — рядок із полями: FUSER_ID (ідентифікатор анонімного користувача з сесії), PRODUCT_ID, QUANTITY, PRICE, CUSTOM_PRICE (прапор ручної ціни), NOTES, PRODUCT_XML_ID і набір полів PROPS — це серіалізовані властивості позиції з b_sale_basket_props.
Робота з кошиком через API:
// Додавання товару
$basket = \Bitrix\Sale\Basket::loadItemsForFUser(
\Bitrix\Sale\Fuser::getId(),
\Bitrix\Main\Context::getCurrent()->getSite()
);
$item = $basket->createItem('catalog', $productId);
$item->setFields([
'QUANTITY' => 2,
'CURRENCY' => 'RUB',
'LID' => 's1',
'PRODUCT_PROVIDER_CLASS' => '\Bitrix\Catalog\Product\CatalogProvider',
]);
$basket->save();
Для AJAX-операцій із кошиком (додати, змінити кількість, видалити) використовується контролер \Bitrix\Sale\Compatible\DiscountCompatibility або власний AJAX-обробник через \Bitrix\Main\Engine\Controller.
Що реально вимагає кастомної розробки
Кастомні властивості позиції. Стандартний кошик не дозволяє додати довільні поля до позиції — наприклад, текст для гравірування, вибраний розмір упаковки або дату доставки конкретного товару. Під капотом це таблиця b_sale_basket_props із полями NAME, VALUE, CODE. Для кастомних властивостей потрібно:
- Додати UI у шаблон сторінки товару (модальне вікно, поля форми)
- При додаванні до кошика передати властивості в AJAX-запиті
- В обробнику додати їх через
$item->getPropertyCollection()->createItem() - Відобразити в шаблоні кошика
Збереження кошика без авторизації. За замовчуванням FUSER_ID — це сесійний ID, і при зміні браузера або пристрою кошик зникає. Для збереження потрібно зберігати FUSER_ID у cookie з довгим TTL (30–90 днів) і при першому відвідуванні створювати запис у b_sale_fuser, прив'язаний до цього cookie. При авторизації — злиття анонімного кошика з кошиком користувача через \Bitrix\Sale\Basket::mergeBasket.
Міні-кошик у хедері з AJAX-оновленням. Стандартний компонент bitrix:sale.basket.small при кожному запиті звертається до БД. На високонавантажених магазинах це помітно: 200 RPS × N запитів до b_sale_basket. Рішення — зберігати лічильник кошика в Redis (через \Bitrix\Main\Data\Cache з тегуванням) і оновлювати лише при змінах, а не при кожному рендері сторінки.
Мультивалютний кошик. При продажу в кількох валютах необхідно коректно перераховувати ціни через CCurrencyRates::ConvertCurrency і зберігати як вихідну ціну у валюті, так і еквівалент у базовій. Стандартний компонент це робить, але без можливості показати «ціну у вашій валюті» поруч із ціною в USD.
Кейс: кошик із конфігуратором для будівельного магазину
Клієнт — інтернет-магазин будівельних матеріалів. Проблема: покупець вибирає плитку і йому потрібно вказати площу укладання, відсоток бою та спосіб укладання (прямо/діагональ). Підсумкова кількість пачок і ціна мають розраховуватися в реальному часі прямо в кошику.
Рішення: розроблено компонент кошика на Vue.js, який спілкується з бекендом через REST API (власний контролер). Конфігуратор — окремий компонент, вбудований у рядок позиції кошика. Дані конфігурації зберігаються в b_sale_basket_props із кодами AREA, BREAKAGE_PCT, LAYOUT_TYPE. При зміні параметрів — перерахунок через AJAX без перезавантаження сторінки. Складність: ціни в каталозі зберігаються за одиницю, а закупівля іде пачками — довелося реалізувати конвертацію в обох напрямках.
Результат: конверсія кошика зросла, тому що клієнт бачить фінальну суму ще до оформлення замовлення, а не отримує уточнення по телефону.
Архітектурні рішення при розробці
Вибір підходу залежить від вимог:
| Підхід | Коли застосовувати | Трудомісткість |
|---|---|---|
| Кастомний шаблон компонента | Тільки візуальні зміни | 1–2 дні |
| Перевизначення компонента | Зміна логіки без сторонніх даних | 3–5 днів |
| Власний компонент + REST API | Складна логіка, Vue/React-фронтенд | 2–4 тижні |
| Headless (Next.js + Бітрікс API) | Повний контроль над фронтом | від 4 тижнів |
При розробці кастомного кошика обов'язково враховуємо:
- Збереження сумісності з модулем
sale— знижки, купони, правила кошика мають продовжувати працювати - Коректний перерахунок при зміні кількості через
OnSaleBasketBeforeSaved - Валідацію на сервері: не можна довіряти ціні, що прийшла з клієнта
- Обробку ситуації «товар закінчився, поки лежав у кошику»
Строки та етапи
Розробка кастомного кошика від аналізу до здачі займає від 5 робочих днів до 6 тижнів залежно від складності:
- Аудит поточного кошика та ТЗ — 1–2 дні
- Розробка серверної частини (API, обробники подій) — 3–10 днів
- Розробка фронтенду — 2–15 днів
- Інтеграція з модулями
sale,catalog,currency— 1–5 днів - Тестування (юніт, інтеграційне, навантажувальне) — 1–3 дні