Когда вариации товаров в WooCommerce перестают работать: кейс с плагином cookie consent

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

Но при этом магазин может незаметно терять деньги с каждой покупки.

Именно такая ситуация произошла на одном из WooCommerce-проектов, который мы поддерживаем.

Проблема: покупатели выбирали одну вариацию, а WooCommerce оформлял другую

Проблема появилась неожиданно.

Покупатели могли открыть вариативный товар, выбрать нужную опцию, добавить товар в корзину и оплатить заказ. Однако в админ-панели WooCommerce в заказ попадала не та вариация, которую выбрал покупатель, а первая доступная вариация товара.

Это была не просто визуальная ошибка на странице товара. Неверная вариация также использовалась при расчёте стоимости заказа.

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

Одновременно часть покупателей столкнулась с другой проблемой: они вообще не могли добавить вариативный товар в корзину.

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

Поиск причины

На сайте использовалась сложная связка WooCommerce-расширений, функционала FunnelKit и кастомной разработки.

Естественно, эти компоненты стали первыми подозреваемыми.

Мы проверили кастомный код, отвечающий за поведение товаров и оформление заказа. Изучили настройки FunnelKit и протестировали, могут ли другие WooCommerce-плагины изменять данные вариации на этапе добавления в корзину или оформления заказа.

Но ни один из этих компонентов не оказался источником проблемы.

Выбранная вариация терялась ещё до того, как заказ доходил до этапа checkout. Это указывало на то, что проблема возникала прямо на странице товара — скорее всего, в момент, когда WooCommerce обрабатывал выбор покупателя.

Неожиданная причина: Cookiebot

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

Cookiebot блокировал или задерживал выполнение некоторых JavaScript-файлов WooCommerce.

WooCommerce активно использует JavaScript для работы с вариативными товарами. Эти скрипты определяют выбранные атрибуты, находят соответствующую вариацию, обновляют отображаемую цену и наличие товара, а также передают корректный ID вариации при добавлении товара в корзину.

Из-за того что часть этих скриптов блокировалась, WooCommerce не мог стабильно определить выбранную покупателем вариацию.

В зависимости от ситуации это приводило к двум разным результатам:

• WooCommerce использовал первую доступную вариацию вместо той, которую выбрал покупатель.
• Вариация вообще не распознавалась, и товар нельзя было добавить в корзину.

С точки зрения конфиденциальности cookie-плагин работал так, как должен. Но его конфигурация оказалась несовместима с конкретной связкой WooCommerce, сторонних плагинов и кастомного функционала на сайте.

Как cookie-плагины могут влиять на WooCommerce

Платформы для управления cookie consent часто контролируют, когда именно скриптам разрешено запускаться. Скрипты могут блокироваться до тех пор, пока посетитель не примет определённую категорию cookie, или пока система не классифицирует их как необходимые.

Это может создавать серьёзные проблемы, если важный e-commerce-скрипт ошибочно попадает в категорию необязательных.

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

• выбор вариаций товара;
• динамическое обновление цены;
• добавление товара в корзину;
• cart fragments;
• валидацию checkout;
• инициализацию платёжных шлюзов;
• автозаполнение адреса;
• расчёт доставки;
• кастомные опции товара.

Чем больше плагинов и кастомных скриптов используется на сайте, тем внимательнее нужно настраивать систему управления cookie.

Решение

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

После корректировки настроек cookie-плагина вариации товаров снова начали выбираться правильно. Покупатели могли добавлять в корзину нужные опции, а в заказы WooCommerce попадали корректные ID вариаций и цены.

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

Мы проверили:

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

Тестировать оба состояния согласия особенно важно. Магазин может работать корректно после того, как посетитель принял все cookie, но ломаться для новых пользователей, которые ещё не дали согласие.

Cookiebot полезен, но его нужно правильно настраивать

Cookiebot и похожие платформы cookie consent могут быть полезными инструментами для соблюдения требований конфиденциальности. Вывод из этого кейса не в том, что от cookie-плагинов нужно отказываться.

Вывод в том, что их необходимо тщательно настраивать.

Автоматическая блокировка скриптов может быть удобной, но её нельзя включать на сложном интернет-магазине без полноценного тестирования. WooCommerce-расширения, конструкторы страниц, checkout-плагины, кастомный JavaScript и сторонние интеграции могут зависеть от скриптов, которые cookie-платформа способна заблокировать или задержать.

Для магазинов со сложной технической конфигурацией важно:

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

Столкнулись с похожей проблемой в WooCommerce?

Когда вариации WooCommerce перестают работать, разработчики часто начинают с отключения товарных плагинов, checkout-расширений или кастомного кода. Это логичные направления для проверки, но не единственно возможные причины.

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

Неправильно настроенный cookie-плагин может блокировать скрипты, которые нужны WooCommerce для корректного распознавания вариаций товара.

В некоторых случаях решение заключается не в том, чтобы удалить систему cookie consent, а в том, чтобы правильно настроить исключения и убедиться, что критически важные e-commerce-скрипты всегда могут запускаться.

Этот кейс стал полезным напоминанием: даже инструмент, установленный ради compliance и безопасности, может повлиять на ключевой функционал интернет-магазина. Когда на WooCommerce-сайт добавляется платформа управления cookie, её нужно тщательно настраивать и обязательно тестировать полный процесс оформления заказа.