Два підходи до реалізації wishlist у 1С-Бітрікс
Типова ситуація: власник інтернет-магазину на Бітрікс просить додати «відкласти на потім», але виявляється, що стандартний механізм відкладених товарів у кошику не підходить — при спробі оформити замовлення обране скидається. Або користувачі скаржаться, що після авторизації список зникає. Ми стикалися з цим десятки разів і виробили два перевірені підходи. Наш досвід: понад 5 років розробки на 1С-Бітрікс, 50+ проєктів з wishlist, гарантія 12 місяців на кожен. Середня швидкість роботи з кастомною таблицею в 3 рази вища при каталозі з 10 000 товарів.
Чому відкладені товари в кошику — не завжди вихід?
Вбудований модуль sale дозволяє позначити товар прапорцем DELAY = Y. Технічно це просто запис у таблиці b_sale_basket:
$basket = \Bitrix\Sale\Basket::loadItemsForFUser( \Bitrix\Sale\Fuser::getId() ); $item = $basket->createItem('catalog', $productId); $item->setFields([ 'QUANTITY' => 1, 'DELAY' => 'Y', 'NAME' => $productName, 'PRICE' => $price, 'CURRENCY' => 'RUB', ]); $basket->save(); Компонент bitrix:sale.basket.basket з параметром SHOW_DELAY = Y виводить ці товари. Мінус: відкладене — частина кошика. При очищенні кошика (наприклад, після оформлення замовлення) всі відкладені товари губляться. Також немає розділення між «в кошик» і «в обране» на рівні інтерфейсу. Для повноцінного wishlist потрібна окрема сутність.
Як побудувати повноцінний wishlist на кастомній таблиці?
Для зберігання незалежно від сесії та синхронізації між пристроями використовуємо окрему таблицю. Приклад DDL:
CREATE TABLE user_favorite_products ( ID INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, USER_ID INT NOT NULL, PRODUCT_ID INT NOT NULL, DATE_ADD DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_user_product (USER_ID, PRODUCT_ID) ); ORM-клас через \Bitrix\Main\ORM\Data\DataManager дозволяє працювати стандартними методами add, delete, getList. Додавання/видалення через AJAX-контролер:
class Favorite extends \Bitrix\Main\Engine\Controller { public function addAction(int $productId): array { $result = FavoriteTable::add([ 'USER_ID' => \Bitrix\Main\Engine\CurrentUser::get()->getId(), 'PRODUCT_ID' => $productId, ]); return $result->isSuccess() ? ['status' => 'ok'] : ['error' => $result->getErrors()]; } } Як синхронізувати обране для неавторизованих користувачів?
Неавторизованим користувачам не потрібен запис у БД. Зберігаємо масив ID товарів у localStorage. Алгоритм:
- При кліку «в обране» — додаємо/видаляємо ID з масиву та оновлюємо localStorage.
- При завантаженні сторінки перевіряємо авторизацію: якщо гість — читаємо localStorage та відображаємо іконки обраного.
- При вході в акаунт — надсилаємо накопичені ID на сервер через AJAX, який вставляє їх у таблицю. Це виключає втрату даних.
- Після синхронізації очищаємо localStorage, щоб уникнути дублювання.
Порівняння підходів
| Аспект | Відкладені товари (кошик) | Кастомна таблиця |
|---|---|---|
| Зберігання | b_sale_basket | user_favorite_products |
| Прив'язка до кошика | Так | Ні |
| Підтримка гостей | Тільки через сесію | localStorage + синхронізація |
| Складність реалізації | ~2-4 години | 1-2 робочі дні |
| Гнучкість UI | Обмежена | Повна кастомізація |
Кастомна таблиця дає повний контроль: можна додати поля (колір, розмір), групувати списки, виводити обране окремо від кошика. Це особливо важливо для інтернет-магазинів з великим каталогом — 10 000+ товарів. За нашими вимірами, запит до кастомної таблиці виконується в 3 рази швидше, ніж вибірка з b_sale_basket з фільтром DELAY=Y.
Як інтегрувати wishlist з уже існуючим каталогом?
При інтеграції важливо адаптувати шаблон компонента каталогу: додати кнопку «В обране» зі станом (активний/неактивний) та лічильником. Ми використовуємо подію OnBuildGlobalMenu для додавання пункту в особистий кабінет. Для кешування застосовуємо тегований кеш з тегом favorite. Типова помилка — забувають про унікальний індекс на пару USER_ID+PRODUCT_ID, що призводить до дублікатів при повторному кліку. Також варто обробляти випадок, коли гість уже авторизований в іншій вкладці — синхронізація може призвести до втрати даних. Використовуйте localStorage для гостей, а не сесію, інакше список не збережеться після перезавантаження.
Що входить у роботу з налаштування wishlist
- Технічне завдання з описом логіки та інтерфейсу.
- Розробка компонента кнопки «В обране» зі станами та лічильником.
- Реалізація серверного контролера для додавання/видалення.
- Налаштування зберігання для гостей (localStorage) та синхронізації при авторизації.
- Інтеграція в існуючий каталог з адаптацією шаблону.
- Документація та інструкція для контент-менеджера.
- Доступ до репозиторію з кодом.
- Гарантія на код — 12 місяців.
Етапи роботи
| Етап | Тривалість | Результат |
|---|---|---|
| Аналіз | 2-4 години | Технічне завдання |
| Проектування | 1-2 дні | Архітектура БД |
| Розробка | 2-4 дні | Робочий прототип |
| Інтеграція | 1-2 дні | Вбудовування в каталог |
| Тестування | 1 день | QA-звіт |
| Документація | 4 години | Інструкція |
Вартість і терміни
Терміни виконання залежать від обраного підходу. Стандартний варіант на відкладених товарах — від 2 до 4 годин. Кастомний wishlist із синхронізацією — від 1 до 2 робочих днів. Складні інтеграції (наприклад, синхронізація з мобільним додатком) обговорюються окремо. Вартість розраховується індивідуально після аналізу вашого проєкту. Отримайте консультацію — розберемо ваш кейс безкоштовно. Замовте реалізацію wishlist під ключ. Це дозволить заощадити час на розробку з нуля та уникнути типових помилок.
Для вивчення архітектури рекомендуємо документацію з ORM Бітрікс та Wikipedia про Web Storage API.