Стандартные вариации WooCommerce хорошо работают, пока у товара несколько понятных комбинаций: размер, цвет, объём. Но если цена зависит от десятка параметров, часть опций должна появляться только после другого выбора, а итоговую конфигурацию нужно сохранить в заказе, обычных variations становится мало.

В такой ситуации нужен отдельный конфигуратор товара WooCommerce, который управляет логикой выбора, считает цену и передаёт результат в корзину без создания тысяч искусственных вариаций.

Ниже разбираю, как такой конфигуратор лучше строить и где чаще всего появляются проблемы.

Когда стандартных вариаций WooCommerce уже недостаточно

Вариации удобны, когда комбинаций немного и каждая из них реально является отдельной товарной единицей со своим SKU, остатком или ценой.

Проблемы начинаются, когда товар собирается из параметров:

• размер по ширине и высоте;
• материал;
• тип покрытия;
• цвет;
• комплектация;
• дополнительные элементы;
• способ монтажа;
• индивидуальные размеры;
• услуги, которые влияют на цену.

Если создать variation для каждой возможной комбинации, их количество растёт очень быстро. Админка становится тяжёлой, управление остатками усложняется, а обновление каталога превращается в отдельную проблему.

Конфигуратор и вариации решают разные задачи

Главное различие простое.

Variation — это заранее существующая комбинация товара.

Конфигуратор — это система правил, которая собирает конкретный вариант из параметров пользователя.

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

Зависимые опции

Одна из ключевых задач — показывать пользователю только те параметры, которые имеют смысл для текущего выбора.

Например:

• после выбора материала становятся доступны только совместимые цвета;
• определённый тип крепления показывается только для конкретной конструкции;
• дополнительная услуга доступна только после выбора нужной комплектации;
• часть опций блокируется при превышении размера;
• для одной модели используется фиксированная цена, для другой — формула.

Если просто скрывать поля JavaScript-кодом, логика быстро становится хрупкой. Лучше хранить зависимости как отдельные правила, которые можно проверять и на клиенте, и на сервере.

Как считать цену

Универсальной формулы здесь нет. Всё зависит от бизнеса.

На практике используются несколько вариантов.

Фиксированная доплата

Опция добавляет к цене заранее известную сумму. Например, +500 ₽ за дополнительный элемент.

Процент от базовой цены

Параметр увеличивает стоимость на заданный процент.

Цена по формуле

Для товаров по индивидуальным размерам цена может зависеть от площади, длины, количества элементов или нескольких коэффициентов сразу.

Итог = базовая цена
      + площадь × ставка материала
      + стоимость выбранных опций
      + дополнительная обработка

Таблица цен

Иногда бизнес уже использует матрицу, где цена зависит от диапазона размеров и выбранной категории. В таком случае формулу лучше не придумывать, а перенести существующие правила в удобную структуру данных.

Почему расчёт нельзя оставлять только в JavaScript

Показывать предварительную цену в браузере удобно, но окончательное значение нельзя доверять данным из frontend.

Пользователь может изменить запрос вручную, подменить значение поля или отправить собственный POST.

Поэтому при добавлении в корзину сервер должен повторно:

1. получить выбранные параметры;
2. проверить допустимые значения;
3. проверить зависимости;
4. пересчитать цену;
5. сохранить нормализованную конфигурацию.

JavaScript в этом случае остаётся интерфейсом, а не единственным источником истины.

Что нужно сохранить в корзине

Если два пользователя выбрали один и тот же базовый товар, но разные параметры, WooCommerce должен различать эти позиции.

Обычно в cart item сохраняются:

• ID или ключ конфигурации;
• выбранные параметры;
• человекочитаемые названия опций;
• данные, необходимые для серверного пересчёта;
• при необходимости технический hash конфигурации.

После этого выбранные данные нужно показывать в корзине и checkout, чтобы покупатель видел, что именно он заказывает.

Конфигурация должна попасть в заказ

Очень частая ошибка — сделать красивый frontend и расчёт цены, но не продумать работу менеджера после оплаты.

В заказе должны сохраниться все параметры, которые нужны для производства, комплектации или обработки.

Лучше сохранять их в metadata позиции заказа, а не одним длинным текстовым полем. Тогда данные проще выводить в письмах, админке, PDF, CRM и внешних интеграциях.

Что делать с остатками

Здесь важно заранее определить модель учёта.

Если каждая конфигурация соответствует реальному SKU, возможно, вариации всё-таки нужны.

Если конфигурация собирается из компонентов, остатки можно контролировать по отдельным элементам.

Если товар производится под заказ, может быть достаточно проверки доступности материалов или ограничений по параметрам.

Нельзя автоматически переносить одну схему на любой магазин. Сначала определяется реальная логика склада, потом под неё строится код.

Когда лучше оставить часть товара вариациями

Кастомный конфигуратор не означает, что variations нужно удалить полностью.

Нормальный гибридный вариант:

• ключевые складские варианты остаются WooCommerce variations;
• дополнительные услуги и параметры работают поверх выбранной variation;
• конфигуратор управляет зависимостями;
• сервер пересчитывает итоговую цену;
• заказ сохраняет и variation, и дополнительные параметры.

Так можно сохранить совместимость с остатками, импортом и другими WooCommerce-процессами.

Админка тоже важна

Если правила конфигуратора меняются раз в год, их можно хранить в коде или конфигурационном файле.

Если менеджер регулярно меняет коэффициенты, опции и зависимости, нужна отдельная редактируемая структура.

Это могут быть:

• кастомные поля товара;
• отдельный settings page;
• специальный custom post type;
• таблица в базе для большой матрицы правил;
• импорт правил из внешней системы.

Выбор зависит от объёма данных и того, кто будет их редактировать.

Производительность на большом каталоге

Если конфигуратор работает на сотнях товаров, нельзя на каждой загрузке страницы вытаскивать всю таблицу правил из базы и передавать её в браузер.

Лучше отдавать только данные текущего товара, кэшировать неизменяемые справочники и загружать тяжёлые зависимости по необходимости.

Отдельно нужно следить, чтобы расчёт не создавал лишние AJAX-запросы при каждом клике пользователя.

Мобильная версия

На смартфоне конфигуратор легко превращается в длинную форму с десятками select.

Поэтому интерфейс лучше разбивать на логические этапы:

1. базовые параметры;
2. зависимые опции;
3. дополнительная комплектация;
4. итог и цена.

При этом выбранные значения не должны сбрасываться при раскрытии следующего блока или пересчёте.

Частые ошибки

• создать тысячи variations вместо правил;
• считать цену только на frontend;
• не валидировать скрытые параметры;
• не сохранять выбор в order item metadata;
• забыть о налогах и валюте;
• сломать стандартный add to cart;
• не учитывать совместимость с кешем;
• загружать все правила каталога на каждой карточке;
• делать интерфейс только под desktop;
• не продумать изменение заказа менеджером.

Когда нужен кастомный конфигуратор

Отдельная разработка оправдана, когда бизнес-правила не укладываются в стандартные variations и готовые add-ons плагины начинают конфликтовать между собой или ограничивают нужную логику.

Кастомное решение можно встроить в действующий магазин без полной переделки каталога, если заранее сохранить стандартный жизненный цикл WooCommerce: товар → корзина → checkout → заказ.

Разработка конфигуратора WooCommerce

Я разрабатываю и дорабатываю WooCommerce под конкретную бизнес-логику: зависимые параметры, расчёт цены, сохранение конфигурации в заказе, интеграции с API и существующим каталогом.

Если уже есть работающий магазин, сначала можно разобрать текущую структуру товаров и определить, что оставить стандартным WooCommerce, а что вынести в отдельную логику.

Подробнее об услуге: разработка и доработка WooCommerce. Для конкретной задачи можно отправить описание через форму связи.