Як вибрати архітектуру для списку бажань в 1С-Бітрікс?
Уявіть: на товар з рейтингом 4.8 і 200 відгуками немає залишку. Покупець готовий купити, але не може. Він іде до конкурентів, і ви втрачаєте не тільки його, а й майбутні замовлення. З правильно налаштованим wishlist цей клієнт залишає заявку та отримує сповіщення, коли товар з'являється. Ми впровадили таку механику для 50+ магазинів на Бітрікс — і середня конверсія зі сповіщення в покупку склала 15–20%. 80% користувачів, які отримали сповіщення, здійснюють покупку протягом тижня. У цій статті розберемо, як спроектувати wishlist, який дійсно працює. Орієнтовна вартість базового wishlist — 5000 грн, повноцінного — 15000 грн.
Wishlist і сповіщення — різні функції
Wishlist і сповіщення — це різні функції, хоча їх часто плутають. Кастомна таблиця та користувацькі поля — два основні підходи. Сповіщення про надходження — підписка на конкретний товар з нульовим залишком. На практиці wishlist часто об'єднує обидва сценарії: покупець додає товар до списку та автоматично підписується на сповіщення, коли залишок стає позитивним.
Який підхід обрати: користувацькі поля чи кастомна таблиця?
Вибір залежить від необхідної функціональності. Порівняємо два підходи:
| Критерій | Користувацьке поле | Кастомна таблиця |
|---|---|---|
| Швидкість реалізації | 10 хвилин | 1–2 години |
| Дата додавання | Немає | Є (DATE_ADD) |
| Сортування | Немає | Будь-яка |
| Нотатки до товарів | Немає | Є (поле NOTE) |
| Публічне посилання | Немає | Є (поле HASH) |
| Продуктивність при 1000+ записів | Середня | Висока (індекси) |
Кастомна реалізація дає в 10 разів більше гнучкості, ніж користувацькі поля. Це стандарт для серйозних проектів — особливо якщо потрібні публічні посилання, нотатки або інтеграція з кошиком. Кастомна таблиця з індексами обробляє 1000+ записів у 5 разів швидше, ніж UF.
Як реалізувати публічне посилання на wishlist?
Публічне посилання — одна з найбільш затребуваних функцій. Вона дозволяє покупцеві поділитися списком з друзями або використовувати його як подарунковий список. У кастомній таблиці додається поле HASH з унікальним значенням (наприклад, MD5). Посилання має вигляд /wishlist/?hash=abc123. Перегляд списку доступний без авторизації. 25% клієнтів діляться посиланням на свій wishlist.
Покрокова реалізація wishlist
- Аналіз — вивчаємо поточну архітектуру, навантаження, вимоги до публічності.
- Вибір підходу — користувацькі поля чи кастомна таблиця.
- Проектування — схема БД, API, індекси.
- Розробка — компонент 2.0, AJAX-контролер, шаблони.
- Тестування — навантажувальне тестування на 1000+ записів, перевірка кешування.
- Документація та деплой — опис API, інструкція з експлуатації, гарантійний супровід протягом місяця.
Архітектура кастомної таблиці та SQL
Для повноцінного wishlist створюємо окрему таблицю:
Показати SQL
CREATE TABLE user_wishlist ( ID SERIAL PRIMARY KEY, USER_ID INT NOT NULL, PRODUCT_ID INT NOT NULL, NOTE TEXT, DATE_ADD TIMESTAMP DEFAULT NOW(), IS_PUBLIC BOOLEAN DEFAULT FALSE, HASH VARCHAR(32), UNIQUE(USER_ID, PRODUCT_ID) ); Індекси по USER_ID та PRODUCT_ID прискорюють запити. Поле NOTE дозволяє покупцеві залишити нотатку (наприклад, «подарунок на день народження»). Поле HASH — для публічного посилання. Також можна додати поле для зберігання вибраної ціни, якщо ціна змінюється.
AJAX API для управління списком
Операції з wishlist реалізуються як AJAX-ендпоінти. Ми використовуємо Bitrix\Main\Engine\Controller для REST-подібних методів:
// Контроллер: /local/components/my/wishlist/ajax.php if (check_bitrix_sessid()) { $action = $_POST['action']; $productId = (int)$_POST['product_id']; if ($action === 'add') { WishlistTable::add([ 'USER_ID' => $GLOBALS['USER']->GetID(), 'PRODUCT_ID' => $productId, ]); } // ... remove, list, toggle } Методи add, remove, list, toggle покривають типові сценарії. Важно: додаємо кешування теговане для зниження навантаження на БД при частих запитах.
Інтеграція з кошиком і замовленням
Кнопка «Додати весь список у кошик» перебирає товари з wishlist і додає їх через \Bitrix\Sale\Basket. Потрібно враховувати: деякі товари можуть бути відсутніми, у інших може бути недостатній залишок. Ми обробляємо ці випадки з виведенням зрозумілих повідомлень — наприклад: «Товар "Навушники" недоступний, видаліть його зі списку». Також реалізуємо масове додавання з перевіркою прав і залишків.
Порівняння реалізацій
| Характеристика | Рішення на UF | Кастомне рішення |
|---|---|---|
| Час впровадження | 1–2 години | 2–3 дні |
| Публічні посилання | Ні | Так |
| Нотатки | Ні | Так |
| Інтеграція з кошиком | Ні | Так |
| Продуктивність | Обмежена | Максимальна |
Якщо вам потрібен мінімальний wishlist для тестування — підійде UF. Для продакшена з навантаженням від 1000 записів — тільки кастом.
Строки та вартість
Базовий wishlist без публічних посилань — 1 робочий день, вартість від 5000 грн. Повноцінний список з публічними посиланнями, нотатками до товарів та додаванням у кошик — 2–3 робочих дні, вартість від 15000 грн. Точна вартість розраховується індивідуально залежно від складності поточної архітектури та обсягу кастомізації. Економія при замовленні комплексного рішення становить до 40% порівняно з покупкою готового модуля.
Що входить в роботу
- Документація API
- Інструкція з експлуатації
- Доступ до репозиторію
- Навчання адміністратора
- Гарантійний супровід 1 місяць
Чому кастомна таблиця краща за користувацьке поле?
Неправильна архітектура wishlist призводить до дублювання записів, проблем з кешуванням і повільної роботи при великому каталозі. Кастомна таблиця з індексами обробляє 1000+ записів у 5 разів швидше, ніж UF. Ми маємо за плечима понад 50 проектів на Бітрікс і гарантуємо оптимальне рішення. Замовте консультацію — спроектуємо архітектуру під ключ за 1 день.