Conditional Shipping Methods WooCommerce - Плагин WordPress

Руководство по настройке Conditional Shipping Methods WooCommerce для управляемой доставки

Conditional Shipping Methods WooCommerce нужен не для расчёта новой стоимости доставки, а для другой задачи: показать покупателю только те способы доставки, которые имеют смысл в текущей корзине, адресе, весе, времени или составе заказа. В этом руководстве разберём, как встроить плагин в уже настроенные зоны WooCommerce, как создавать rulesets, чем отличаются Conditions и Actions, как проверить результат в корзине и checkout, а также как диагностировать ситуации, когда метод доставки не скрывается или пропадает слишком рано.

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

Особенность таких плагинов в том, что они зависят не только от собственных настроек. На результат влияют shipping zones WooCommerce, порядок зон, товары в корзине, классы доставки, сторонние live rates-плагины, настройки бесплатной доставки и даже язык админ-панели в мультиязычном магазине. Поэтому хорошая настройка начинается не с кнопки Add ruleset, а с короткого аудита текущей логики доставки.

Если вы хотите просто добавить один фиксированный тариф, одного этого плагина будет мало. Если же методы уже есть, но покупатель видит лишние варианты - например, платную доставку рядом с бесплатной, live rate для товара с отдельной перевозкой или экспресс-доставку после рабочего времени - Conditional Shipping Methods становится полезным слоем управления.

Как плагин встраивается в логику доставки WooCommerce

В WooCommerce покупатель видит способы доставки не глобально по всему магазину, а внутри подходящей shipping zone. Сначала WooCommerce определяет зону по адресу, затем рассчитывает методы этой зоны, затем выводит их в корзине или на странице оформления заказа. Conditional Shipping Methods подключается к этому процессу как фильтр видимости: он берёт уже доступные методы и применяет к ним правила.

Это важно для ожиданий. Плагин не заменяет shipping zone, не создаёт carrier API, не делает тариф из пустоты и не чинит неправильно настроенный Flat Rate. Если исходный метод доставки не появился из-за зоны, адреса, ограничений carrier-плагина или отсутствующего веса товара, правило Conditional Shipping Methods не сможет показать его покупателю. Сначала метод должен быть рассчитан WooCommerce или сторонним shipping-плагином, и только потом его можно скрывать, оставлять единственным вариантом или исключать при выполнении условий.

Два слоя: Conditions и Actions

Логика плагина строится вокруг двух блоков. Conditions отвечают на вопрос "когда правило должно сработать". Это может быть вес корзины, цена, конкретный товар, категория, тег, shipping class, доступность другого shipping method, наличие zero-cost shipping method, день недели, время или локация покупателя. Actions отвечают на вопрос "что сделать со способами доставки": оставить только выбранные методы, скрыть выбранные методы или скрыть все платные методы.

Такой подход кажется простым, но именно он позволяет решать сценарии, которые сложно аккуратно закрыть обычной сортировкой shipping methods. Например, можно скрывать FedEx, если в корзине есть товар с классом "Fresh food"; скрывать UPS, если общий вес превысил рабочий лимит; оставлять только local pickup для близкого региона; убирать платные методы, когда бесплатная доставка уже доступна.

Почему правило срабатывает после расчёта доставки

В документации Octolize отдельно указано, что rulesets запускаются после расчёта стоимости доставки в корзине. Практический смысл такой: Conditional Shipping Methods не должен угадывать, какие методы могли бы быть доступны, он работает с фактическим набором, который уже получил WooCommerce. Поэтому при отладке всегда двигайтесь от базы к фильтру:

1. Проверьте, что адрес покупателя попадает в нужную shipping zone.
2. Убедитесь, что нужные методы добавлены в эту зону и включены.
3. Проверьте, что сторонние live rates или table rate-плагины сами возвращают тарифы.
4. Только после этого включайте или меняйте rulesets Conditional Shipping Methods.

Если метод доставки не появляется даже при выключенном Conditional Shipping Methods, проблема не в ruleset. Сначала исправьте зону, исходный shipping method, вес/размер товара, адрес или carrier-интеграцию.

Кому подойдёт такой способ управления доставкой

Плагин особенно полезен магазинам, где список доставки меняется не только по региону, но и по содержимому заказа. Стандартные shipping zones хорошо отвечают на вопрос "куда отправляем", но хуже справляются с вопросами "что именно отправляем", "какой вес в корзине", "есть ли бесплатная доставка", "можно ли показывать carrier rate для этого класса товаров". Именно здесь появляется отдельный слой условной видимости.

Подходящие сценарии

Conditional Shipping Methods стоит рассматривать, если в магазине уже есть рабочие способы доставки, но их нужно показывать более избирательно. Типичные ситуации:

• Покупатель набрал сумму для бесплатной доставки, и платные методы больше только отвлекают.
• Некоторые товары нельзя отправлять обычным carrier-методом из-за веса, свежести, габаритов или внутренних правил магазина.
• Live rates от UPS, FedEx, USPS или DHL Express нужны не всегда, а только для части заказов.
• Нужно переключать доставку по shipping class, product category, tag или конкретным товарам.
• Есть рабочие интервалы, после которых same-day или express delivery показывать нельзя.
• В мультиязычном магазине правила завязаны на классы доставки или категории и требуют отдельной проверки переводов.

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

Когда лучше выбрать другой инструмент

Плагин может не подойти, если вам нужно рассчитывать стоимость по сложной таблице тарифов, добавлять надбавки, строить price/weight ranges внутри одного метода или создавать новый shipping method с собственной формулой. В таком случае ближе по задаче будет table rate-плагин, например Flexible Shipping PRO или WooCommerce Table Rate Shipping. Conditional Shipping Methods можно использовать вместе с такими решениями, но его роль останется другой: фильтрация видимости уже рассчитанных вариантов.

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

Что проверить перед установкой и первым ruleset

Подготовка экономит больше времени, чем попытка настроить правило "на глаз". Conditional Shipping Methods опирается на данные WooCommerce, поэтому перед установкой нужно убедиться, что эти данные пригодны для логики условий. Для небольшого магазина хватит короткой проверки, для каталога с несколькими типами доставки лучше сделать мини-карту доставки.

Shipping zones и методы доставки

Откройте WooCommerce -> Settings -> Shipping -> Shipping zones и проверьте, как покупатель попадает в зоны. WooCommerce применяет первую подходящую зону сверху вниз, а покупатель может соответствовать только одной зоне. Если региональная зона стоит ниже общей, покупатель может увидеть не те методы, и Conditional Shipping Methods будет фильтровать уже неправильный набор.

Для каждой зоны проверьте:

• Название зоны понятно администратору и не дублирует другую зону.
• Регионы, страны, штаты и почтовые коды соответствуют реальной доставке.
• Методы доставки включены и имеют разные понятные названия.
• Методы, которыми управляет сторонний плагин, сами возвращают результат без Conditional Shipping Methods.
• Порядок методов внутри зоны не маскирует проблему с выбранным по умолчанию вариантом.

Товары, shipping classes и вес

Если правила будут строиться по весу или shipping class, проверьте товары до создания ruleset. В официальных примерах Octolize для weight-сценария сначала проверяется вес товаров, а для shipping class-сценария - назначение нужного класса доставки. Это не формальность: пустой вес, неверный class или незаполненная вариация могут сделать условие бесполезным.

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

Checkout, блоки и кеш

Octolize указывает совместимость плагина с WooCommerce Block Checkout в changelog. Это полезно, но не отменяет проверки на конкретной теме и наборе расширений. Checkout чувствителен к кешу, фрагментам корзины, AJAX-пересчёту, сторонним payment/shipping extension и кастомным шаблонам. Перед настройкой правил сделайте тестовый заказ на staging-сайте или хотя бы в период низкой нагрузки.

Безопасный порядок: сначала проверьте доставку с выключенными rulesets, затем включите один ruleset, затем меняйте только одно условие за раз. Так вы быстрее поймёте, что именно изменило checkout.

Установка и первичная проверка в админ-панели

Установка не отличается от обычного премиального WordPress-плагина. В документации Octolize описан путь через Plugins -> Add New -> Upload Plugin: загрузить ZIP-архив, установить и активировать. Альтернативный путь через FTP подходит администраторам, которые работают с сервером напрямую, но для большинства магазинов достаточно загрузки архива через админ-панель.

Куда перейти после активации

После установки в настройках доставки WooCommerce должен появиться пункт Conditional Shipping Methods. Официальный путь: WooCommerce -> Settings -> Shipping -> Conditional Shipping Methods. Если пункта нет, проверьте, активирован ли плагин, не скрыт ли раздел из-за прав пользователя и нет ли фатальной ошибки в списке плагинов.

На общем экране плагина сначала включается основная функциональность через Enable/Disable. Пока эта галочка выключена, созданные rulesets не должны влиять на корзину. Это удобно для подготовки: можно собрать правила, проверить названия и включить их, когда готов тестовый сценарий.

Первый контрольный тест без правил

Перед созданием ruleset откройте тестовую корзину и проверьте исходное состояние. Добавьте товар, заполните адрес доставки и убедитесь, что WooCommerce показывает ожидаемые методы. Запишите, какие методы видны до применения фильтра: например USPS Free Shipping, FedEx, UPS или Dedicated delivery. Этот снимок состояния нужен, чтобы потом понять, действительно ли правило изменило вывод.

Если исходные методы не видны, не переходите к настройке Conditional Shipping Methods. Проверьте shipping zone, географию, вес, стоимость, настройки free shipping, API live rates и ошибки checkout. Плагин должен управлять работающей доставкой, а не заменять базовую отладку WooCommerce.

Настройка ruleset: от условия к действию

Ruleset - это отдельный набор правил, который можно включить, назвать и привязать к условиям. Название ruleset не видно покупателю, но оно критично для поддержки. Через месяц после настройки фраза "Rule 1" не поможет понять, что правило должно делать. Лучше писать конкретно: "Hide paid methods when free shipping is available", "Hide FedEx for Fresh food", "Disable UPS over weight limit".

Основные настройки ruleset

На экране ruleset сначала включите Enabled и задайте Ruleset name. Не включайте новое правило сразу на живом checkout, если вы ещё не подготовили тестовую корзину. Для магазинов с активными продажами разумнее сначала настроить правило, временно оставить его выключенным, затем включить на короткое тестовое окно.

Дальше настройка делится на две таблицы. В Conditions вы выбираете критерий, по которому правило сработает. В Actions вы выбираете, что произойдёт со способами доставки. Если условий несколько, документированный интерфейс позволяет добавлять AND и OR. Это мощная возможность, но её легко усложнить. Начинайте с одного условия, убедитесь, что оно работает, затем добавляйте второе.

Как выбирать Conditions

Официальная документация группирует условия по нескольким категориям. Для практики удобнее думать не категориями интерфейса, а вопросами магазина:

• Что лежит в корзине? Используйте Product, Product tag, Product category или Shipping class.
• Какие параметры у заказа? Используйте Weight или Price для всей корзины или package.
• Какие методы уже доступны? Используйте Shipping method или Zero-cost shipping method.
• Когда и куда отправляем? Используйте Day of the week, Time of the day или Location.

Для условий с выбором объектов доступны логические варианты вроде any of, all of и none of. На практике any of подходит для большинства запретов: если в корзине есть хотя бы один товар из класса "Fragile" или "Fresh food", скрываем неподходящий метод. all of нужен реже, когда сценарий должен сработать только при полном совпадении набора. none of полезен для обратных правил, но его сложнее читать, поэтому не используйте его без необходимости.

Как выбирать Actions

Доступные действия отличаются по степени жёсткости. Enable only selected shipping methods оставляет покупателю только выбранные методы, если условие выполнено. Это удобно, когда нужно явно направить заказ в один безопасный канал доставки. Disable only selected shipping methods скрывает конкретные методы и оставляет остальные. Это хороший выбор для исключения carrier rate, который не подходит определённым товарам. Hide all paid shipping methods закрывает популярный сценарий, когда бесплатная доставка уже доступна и платные варианты нужно убрать.

Выбирайте самое узкое действие, которое решает задачу. Если нужно убрать только FedEx для свежих продуктов, не оставляйте "только Dedicated delivery" без причины, потому что позже в зоне может появиться другой допустимый метод. Если нужно показать покупателю только бесплатный метод, наоборот, действие Hide all paid shipping methods будет понятнее и безопаснее ручного списка всех платных вариантов.

Порядок условий и поддержка правил

Документация указывает, что условия учитываются по порядку в таблице и их можно перетаскивать. Это значит, что ruleset должен читаться сверху вниз без загадок. Ставьте более конкретное условие выше, а общее ниже. Например, сначала shipping class "Fresh food", потом cart/package, затем действие. Для сложных наборов не пытайтесь уместить всё в один ruleset: иногда два простых правила легче поддерживать, чем одно универсальное.

Хороший ruleset объясняет сам себя: из названия, Conditions и Actions видно, какую бизнес-задачу он закрывает. Если для понимания правила нужно открыть отдельную таблицу в Notion, значит правило стоит упростить или переименовать.

Сценарии условий: free shipping, shipping class, вес и время

У Conditional Shipping Methods есть несколько сценариев, которые особенно часто встречаются в WooCommerce-магазинах. Их нельзя сводить к одному шаблону, потому что у каждого другая причина и другой способ проверки. Free shipping связан с уже доступным zero-cost методом, shipping class - с товарными данными, weight - с числовым порогом, day/time - с операционным расписанием.

Zero-cost shipping method и бесплатная доставка

Официальный usage example Octolize показывает сценарий, где покупатель достигает порога бесплатной доставки, после чего USPS становится zero-cost методом, а платные FedEx и UPS скрываются. Логика хороша тем, что правило не пытается само считать маркетинговый порог. Оно смотрит на факт: в корзине уже доступен метод с нулевой стоимостью. Если он есть, платные методы можно убрать.

Проверять такой сценарий нужно двумя корзинами. В первой сумма ниже порога, поэтому должны быть видны платные методы. Во второй сумма выше порога, бесплатный метод доступен, а платные методы скрыты. Если бесплатный метод не появляется, ищите проблему в настройке free shipping, Flexible Shipping или shipping zone, а не в Action.

Shipping class для специальных товаров

Shipping class удобен, когда товарная группа важнее конкретного SKU. Например, скоропортящиеся продукты, крупные предметы, хрупкие товары или позиции с отдельной перевозкой. В официальном примере Octolize товар с классом Fresh food скрывает FedEx live rates и оставляет dedicated delivery. Это лучше, чем привязка к отдельным названиям товаров, потому что каталог меняется, а класс доставки остаётся управляемым признаком.

Перед таким правилом проверьте, что shipping class назначен не только основному товару, но и нужным вариациям, если магазин использует variable products. Затем протестируйте корзину с обычным товаром, с одним специальным товаром и со смешанной корзиной. Смешанная корзина особенно важна: именно там часто проявляются ошибки условий.

Вес и пороги перевозчика

Weight-сценарий нужен, когда carrier method допустим только до определённого веса. В usage examples Octolize показан вариант, где UPS live rates скрываются, если общий вес корзины превышает порог, а dedicated delivery остаётся доступной. С точки зрения поддержки это один из самых прозрачных сценариев: вес можно увидеть в товарных данных, порог можно записать в ruleset, результат можно проверить тестовой корзиной.

Главная ловушка - единицы измерения. Условие Weight работает в соответствии с weight unit, выбранной в настройках WooCommerce. Не копируйте число из чужого примера без проверки единиц магазина. Если магазин использует килограммы, тестируйте килограммы; если фунты, тестируйте фунты. Для порога используйте небольшую "зону после границы": если метод должен скрыться выше 50 кг, тестовая корзина на 50.001 кг понятнее, чем ровно 50 кг.

День недели, время и локация

Условия Day of the week, Time of the day и Location помогают не показывать варианты, которые операционно нельзя выполнить. Например, same-day delivery после закрытия склада, weekend delivery в регионе без выходной службы или local pickup вне локальной зоны. Эти правила особенно важно тестировать на реальном часовом поясе сайта и на разных адресах.

Не используйте time-based правило как единственную защиту от невыполнимой доставки. Добавьте понятное описание метода доставки, настройте cut-off внутри carrier/fulfillment-процесса, если он есть, и оставьте персоналу понятную инструкцию, как временно выключить ruleset при праздниках или форс-мажоре.

Практический пример: скрываем платные методы после бесплатной доставки

Теперь соберём конкретный сценарий, который хорошо показывает механику плагина и легко проверяется. Цель: когда покупатель набирает корзину до порога бесплатной доставки, в checkout остаётся только бесплатный способ, а платные carrier methods исчезают. Это снижает путаницу и убирает ситуацию, когда покупатель случайно выбирает платную доставку при доступном бесплатном варианте.

Цель и подготовка

Для примера предположим, что в одной shipping zone уже есть три метода: бесплатный USPS через Flexible Shipping или стандартный free shipping, а также платные FedEx и UPS. Free shipping должен становиться доступным только после заданной суммы корзины. Conditional Shipping Methods будет не рассчитывать этот порог, а реагировать на появление zero-cost shipping method.

Перед настройкой проверьте:

• Все три метода видны в нужной shipping zone, когда правила плагина выключены.
• Free shipping становится доступен при нужной сумме заказа.
• Платные методы имеют корректную стоимость и не возвращают ошибку.
• Тестовый адрес покупателя попадает именно в нужную зону.

Шаги настройки

1. Перейдите в WooCommerce -> Settings -> Shipping -> Conditional Shipping Methods.
2. Убедитесь, что основная настройка Enable/Disable включена.
3. В таблице Rulesets нажмите Add ruleset.
4. Включите Enabled и назовите правило, например Hide paid methods when free shipping is available.
5. В Conditions выберите Zero-cost shipping method и область cart.
6. В Actions выберите Hide all paid shipping methods.
7. Сохраните изменения и очистите тестовую корзину, если она уже кешировала старый набор методов.

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

Проверка результата

Соберите две тестовые корзины. Первая должна быть ниже порога бесплатной доставки: платные методы остаются видимыми, zero-cost method отсутствует или неактивен. Вторая должна быть выше порога: бесплатный метод появляется, а платные методы скрываются. Проверьте результат не только в cart, но и в checkout, потому что тема или checkout blocks могут показывать элементы по-разному.

Мини-итог: если zero-cost method появился, а платные методы не скрылись, проверяйте включение ruleset, Debug Mode и выбранный Action. Если zero-cost method не появился, возвращайтесь к настройкам free shipping и shipping zone.

Нюанс для смешанных корзин

Если магазин продаёт товары с разной логистикой, бесплатная доставка может быть допустима не для всех категорий. В таком случае не торопитесь глобально скрывать платные методы. Сначала решите бизнес-правило: бесплатная доставка применяется ко всей корзине или только к обычным товарам? Если часть корзины требует dedicated delivery, возможно, понадобится отдельный ruleset по shipping class, который будет оставлять специальный метод даже при бесплатной доставке для обычных товаров.

Как проверять результат на сайте и не пропустить скрытую ошибку

Проверка результата - отдельный этап, а не быстрый взгляд на checkout. Условная доставка часто ломается не полностью, а в одном конкретном сочетании: другой регион, вариативный товар, сумма возле порога, другой язык, блоковый checkout, пустой вес или кешированная корзина. Чтобы не ловить это на реальных заказах, используйте матрицу тестов.

Мини-матрица тестов

Для каждого нового ruleset сделайте минимум четыре проверки:

• Корзина, где условие не выполнено: метод должен остаться видимым.
• Корзина, где условие выполнено: метод должен скрыться или остаться единственным, в зависимости от Action.
• Адрес из другой shipping zone: правило не должно создавать неожиданный результат.
• Смешанная корзина: обычный товар плюс товар с shipping class, категорией или тегом, который участвует в условии.

Если магазин мультиязычный, добавьте проверки для каждого языка, где участвуют shipping classes или product categories. Официальный пример Octolize для WPML подчёркивает, что классы и категории должны быть переведены, а правила при необходимости нужно повторить в нужной backend language. Это не универсальная проблема всех сайтов, но для WPML-магазина её лучше проверить заранее.

Где смотреть логи

Для отладки включается Debug Mode в общих настройках плагина. Логи доступны в WooCommerce -> Status -> Logs. Используйте их как временный инструмент: включили, воспроизвели сценарий, посмотрели, какие правила сработали, выключили или оставили только на период активной диагностики.

Лог полезен не только при ошибке "не работает". Он помогает увидеть, что правило сработало слишком широко. Например, вы хотели скрывать UPS только для тяжелой мебели, а правило сработало для любой корзины с аксессуаром из той же категории. В таком случае проблема не в Action, а в слишком общем Condition.

Что считать успешной проверкой

Успех - это не просто исчезновение метода доставки. Успешная проверка включает пять признаков: правильная shipping zone, правильный набор товаров, ожидаемое условие, правильный Action и понятный результат в cart/checkout. Если покупатель видит только допустимые способы доставки, staff понимает причину, а лог подтверждает правило, настройку можно переносить в рабочий режим.

Мультиязычные магазины, live rates и сторонние методы

Conditional Shipping Methods заявлен как standalone-плагин: для базовой работы ему не нужен дополнительный плагин, и он совместим с default shipping methods WooCommerce и Flexible Shipping. При этом реальные магазины часто используют live rates, table rate, pickup points, currency switchers, WPML и кастомные checkout-плагины. Здесь важно не обещать "всё будет работать", а правильно выстроить проверку совместимости.

Live rates: сначала carrier, потом visibility

Если правило должно скрывать UPS, FedEx, USPS или DHL Express Live Rates, сначала убедитесь, что live rates сами возвращают тарифы. Проверьте API credentials, origin address, package weight, dimensions, destination и ограничения carrier. Conditional Shipping Methods не должен быть первым местом диагностики carrier-ошибок. Его включают после того, как live rate уже появился в checkout.

Для live rates особенно полезно действие Disable only selected shipping methods. Оно скрывает конкретный carrier, но не ломает остальные методы в зоне. Если carrier возвращает несколько сервисов, выбирайте именно тот набор methods, который должен исчезнуть, и проверяйте все сервисные варианты в checkout.

WPML и переводы классов доставки

Официальный usage example описывает ситуацию с WPML multi domain, где правила по shipping classes и categories требуют переведённых терминов и настройки в соответствующей backend language. Практический вывод простой: если условие опирается на сущность каталога, а сайт мультиязычный, тестируйте не только русский или английский checkout, но и язык, в котором покупатель реально оформляет заказ.

Если правило работает на одном языке и не работает на другом, проверьте перевод shipping class, category, product tag, а затем убедитесь, что ruleset сохранён в нужном административном контексте. Не дублируйте правила вслепую: сначала зафиксируйте, какая сущность не сопоставилась.

Block Checkout и классический checkout

Changelog продукта указывает совместимость с WooCommerce Block Checkout. Это полезный сигнал поддержки, но разные темы, блоки и сторонние checkout-плагины могут менять внешний вывод методов. Поэтому при проверке сохраняйте один и тот же сценарий и сравнивайте cart и checkout. Если в cart правило видно, а в checkout нет, проблема может быть не в Conditions, а в перерисовке блока, кешировании или стороннем checkout-расширении.

Практика поддержки: как не превратить правила в хаос

Условная доставка быстро разрастается. Сегодня нужно скрыть платные методы при бесплатной доставке, завтра - исключить UPS для тяжелых товаров, затем добавить time-based правило для same-day. Если не ввести простые правила поддержки, через несколько месяцев никто не поймёт, какое правило отвечает за конкретный checkout.

Называйте rulesets как бизнес-сценарии

Название ruleset должно объяснять не интерфейс, а бизнес-смысл. Плохо: Rule 3, Hide methods, Delivery fix. Хорошо: Hide paid methods when free shipping is available, Disable FedEx for Fresh food class, Disable UPS when cart weight is above limit. Такие названия помогают читать Debug Mode и быстрее отвечать на вопрос поддержки.

Один ruleset - одна причина

Не смешивайте в одном ruleset маркетинговую free shipping-логику, ограничения carrier и рабочие часы склада. Технически это может быть возможно через AND/OR, но поддерживать такую конструкцию сложно. Лучше создать несколько понятных rulesets и проверять их по отдельности. Исключение - когда несколько условий действительно описывают одну причину, например shipping class плюс cart/package scope.

Фиксируйте тестовые корзины

Для каждого важного ruleset заведите короткую внутреннюю заметку: какие товары добавить, какой адрес использовать, какая сумма или вес должны быть в корзине, какой результат ожидается. Это не обязательно отдельная система документации; достаточно записи в базе знаний магазина. Главное, чтобы следующий администратор мог воспроизвести проверку без догадок.

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

Частые проблемы и диагностика Conditional Shipping Methods

Проблемы с условной доставкой почти всегда лежат на границе нескольких систем: WooCommerce zones, товарные данные, сторонние shipping methods, кеш, checkout и rulesets. Поэтому диагностика должна идти по цепочке, а не через случайное переключение галочек.

Метод доставки не скрывается

Симптом: покупатель видит FedEx, UPS, Flat Rate или другой метод, хотя условие должно было его скрыть.

Возможная причина: ruleset выключен, Condition не совпал, выбран не тот shipping method в Action, корзина не пересчиталась, метод имеет другое техническое имя или правило проверяется не в той shipping zone.

Что проверить: включён ли Enable/Disable, включён ли конкретный Enabled ruleset, совпадает ли тестовая корзина с условием, виден ли метод при выключенном ruleset, есть ли запись в Debug Mode.

Как исправить: упростите правило до одного Condition, сохраните, очистите тестовую корзину, смените адрес, повторите checkout. Если Action выбирает конкретный метод, перепроверьте, что выбран именно тот instance shipping method, который появляется в зоне.

Когда откатить: если метод остаётся видимым на живом checkout и вы не можете быстро понять причину, временно выключите только проблемный ruleset, а не весь блок доставки.

Скрылись все способы доставки

Симптом: покупатель видит сообщение WooCommerce о недоступной доставке или пустой список методов.

Возможная причина: действие слишком жёсткое, правило оставляет только метод, который в текущей zone не рассчитался, shipping zone не содержит fallback-метода, live rate не вернул тариф, или несколько rulesets одновременно скрыли разные варианты.

Что проверить: выключите Conditional Shipping Methods и убедитесь, что базовые методы есть. Затем включайте rulesets по одному. Проверьте shipping zone, адрес, вес, стоимость корзины и ошибки live rates.

Как исправить: замените Enable only selected shipping methods на более мягкое Disable only selected shipping methods, если сценарий допускает несколько fallback-методов. Добавьте отдельный доступный метод в zone, если бизнес-логика требует запасной вариант.

Когда откатить: если ошибка затрагивает много заказов, выключите новый ruleset и верните checkout к базовому набору методов до анализа логов.

Правило работает в cart, но не видно в checkout

Симптом: в корзине методы скрываются корректно, а на странице оформления заказа появляются снова или обновляются не сразу.

Возможная причина: checkout blocks, тема, кеш, стороннее checkout-расширение или AJAX-пересчёт доставки показывают старое состояние до обновления адреса.

Что проверить: повторите сценарий в приватном окне, смените адрес, очистите cart fragments, временно выключите кеш для cart/checkout, проверьте классический и блоковый checkout, если сайт находится на стадии разработки.

Как исправить: исключите страницы cart и checkout из агрессивного кеша, проверьте конфликт с темой на staging, обновите WooCommerce и shipping-плагины в контролируемом окне. Не добавляйте JS, который вручную скрывает строки доставки: это может сломать выбор shipping rate.

Когда откатить: если поведение отличается только в кастомном checkout, временно верните стандартный блок/шаблон на staging и сравните результат перед изменением правил.

Shipping class или категория не срабатывает

Симптом: товар с нужным классом есть в корзине, но правило его не распознаёт.

Возможная причина: class назначен не той вариации, category/tag не тот, в мультиязычном магазине не сопоставлен перевод, или выбран all of вместо any of.

Что проверить: откройте товар и вариации, проверьте shipping class, затем соберите корзину только с этим товаром. В WPML-сценарии проверьте переводы классов и backend language, как рекомендует Octolize.

Как исправить: назначьте class на правильном уровне товара, замените all of на any of, если достаточно одного совпадения, и пересохраните ruleset в нужном языковом контексте.

Когда откатить: если правило зависит от каталога, который сейчас массово редактируется, лучше временно выключить его и включить после завершения правок товаров.

Правило по весу работает около порога нестабильно

Симптом: при близком весе корзины метод то скрывается, то остаётся видимым.

Возможная причина: округление, разные единицы веса, отсутствие веса у части товаров, package splitting или неверно выбранная область cart/package.

Что проверить: единицу веса в WooCommerce, вес каждого товара, вариации, упаковку, cart/package scope и тестовую корзину чуть ниже и чуть выше порога.

Как исправить: используйте явную границу после порога, заполните вес у всех товаров, уточните cart или package в Condition. Если магазин делит заказ на packages, тестируйте именно package-логику, а не только общий вес корзины.

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

Когда стоит использовать Conditional Shipping Methods WooCommerce

Conditional Shipping Methods WooCommerce будет удачным выбором, если в магазине уже есть понятные методы доставки, но покупатель видит лишние или неподходящие варианты. Плагин особенно силён в сценариях "если условие выполнено, измени видимость methods": бесплатная доставка скрывает платные варианты, shipping class отключает carrier, вес переводит заказ на dedicated delivery, время ограничивает срочную доставку.

Перед внедрением проверьте базу: shipping zones, методы, вес, classes, free shipping, live rates и checkout. После внедрения проверьте результат тестовой матрицей, включите Debug Mode только на время диагностики и сохраните короткую инструкцию для поддержки. Если всё сходится, можно скачать последнюю версию Conditional Shipping Methods WooCommerce и тестировать его на своём сценарии доставки.

Если же вам нужно рассчитывать сложные тарифы с нуля, добавлять стоимость по диапазонам или управлять оплатами, начните с альтернативного инструмента и вернитесь к Conditional Shipping Methods только как к слою фильтрации. Такой выбор сэкономит время и уменьшит риск сложных rulesets, которые пытаются заменить неподходящий тип плагина.