Wishlist в 1С-Битрикс: выбор архитектуры от UF до кастомной таблицы
Представьте: на товар с рейтингом 4.8 и 200 отзывами нет остатка. Покупатель готов купить, но не может. Он уходит к конкурентам, и вы теряете не только его, но и будущие заказы. С правильно настроенным wishlist этот клиент оставляет заявку и получает уведомление, когда товар появляется. Мы внедрили такую механику для 50+ магазинов на Битрикс — и средняя конверсия из уведомления в покупку составила 15–20%. В этой статье разберём, как спроектировать wishlist, который действительно работает.
Wishlist и уведомления — разные функции
Wishlist и уведомления — это разные функции, хотя их часто путают. Кастомная таблица и пользовательские поля — два основных подхода. Уведомление о поступлении — подписка на конкретный товар с нулевым остатком. На практике wishlist часто объединяет оба сценария: покупатель добавляет товар в список и автоматически подписывается на уведомление, когда остаток становится положительным.
Какой подход выбрать: пользовательские поля или кастомная таблица?
Выбор зависит от требуемой функциональности. Сравним два подхода:
| Критерий | Пользовательское поле | Кастомная таблица |
|---|---|---|
| Быстрота реализации | 10 минут | 1–2 часа |
| Дата добавления | Нет | Есть (DATE_ADD) |
| Сортировка | Нет | Любая |
| Заметки к товарам | Нет | Есть (поле NOTE) |
| Публичная ссылка | Нет | Есть (поле HASH) |
| Производительность при 1000+ записей | Средняя | Высокая (индексы) |
Кастомная реализация даёт в 10 раз больше гибкости, чем пользовательские поля. Это стандарт для серьёзных проектов — особенно если нужны публичные ссылки, заметки или интеграция с корзиной.
Как реализовать публичную ссылку на wishlist?
Публичная ссылка — одна из самых востребованных функций. Она позволяет покупателю поделиться списком с друзьями или использовать его как подарочный список. В кастомной таблице добавляется поле HASH с уникальным значением (например, md5 от ID). Ссылка имеет вид /wishlist/?hash=abc123. Просмотр списка доступен без авторизации. Важно: hash генерируется случайным образом, чтобы никто не мог угадать чужой список.
Пошаговая реализация 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 рабочий день, стоимость от $140–200. Полноценный список с публичными ссылками, заметками к товарам и добавлением в корзину — 2–3 рабочих дня, стоимость от $320–460. Точная стоимость рассчитывается индивидуально в зависимости от сложности текущей архитектуры и объёма кастомизации. Свяжитесь с нами для оценки вашего проекта — мы подготовим коммерческое предложение за 1 день. Экономия при заказе комплексного решения составляет до 40% по сравнению с покупкой готового модуля.
Почему кастомная таблица лучше пользовательского поля?
Неправильная архитектура wishlist приводит к дублированию записей, проблемам с кэшированием и медленной работе при большом каталоге. Кастомная таблица с индексами обрабатывает 1000+ записей в 5 раз быстрее, чем UF. Мы имеем за плечами более 50 проектов на Битрикс и гарантируем оптимальное решение. Закажите консультацию — спроектируем архитектуру под ключ за 1 день.