Стандартные shipping zones WooCommerce решают базовую задачу: определить методы доставки по стране, региону или почтовому индексу. Но реальная логистика часто сложнее.
Например, бесплатная доставка действует только от определённой суммы, тяжёлый товар требует отдельного тарифа, некоторые категории нельзя отправлять выбранным способом, а заказ из нескольких типов товаров должен рассчитываться по специальному правилу.
В таких случаях нужны условия доставки WooCommerce, которые анализируют состав корзины и возвращают только допустимые методы и корректную стоимость.
Чем эта задача отличается от обычных shipping zones
Shipping zone отвечает в первую очередь на вопрос куда отправляется заказ.
Кастомное shipping rule дополнительно отвечает на вопросы:
- что лежит в корзине;
- каков общий вес;
- какова сумма заказа;
- есть ли товары определённых категорий;
- есть ли смешанная корзина;
- применён ли купон;
- какой выбран способ оплаты;
- нужно ли показать, скрыть или изменить стоимость конкретного метода.
То есть зона может оставаться стандартной WooCommerce, а поверх неё работает отдельная бизнес-логика.
Доставка по весу
Простейший пример — несколько диапазонов веса.
| Вес корзины | Логика |
|---|---|
| до 2 кг | обычный тариф |
| 2–10 кг | повышенный тариф |
| 10–30 кг | грузовая доставка |
| более 30 кг | индивидуальный расчёт или отдельный перевозчик |
Важно учитывать именно фактический вес товаров и количества в корзине. Если у части каталога вес не заполнен, правило может работать непредсказуемо, поэтому сначала нужно привести данные товаров в порядок.
Бесплатная доставка от суммы заказа
Второй распространённый сценарий — бесплатная доставка после достижения минимальной суммы.
Но бизнесу нужно заранее решить, от какой именно суммы считается порог:
- до скидок или после скидок;
- с налогом или без;
- с учётом gift card;
- с учётом уже начисленной доставки;
- для всей корзины или только для определённых товаров.
Если эти правила не зафиксировать, клиент и магазин могут считать порог по-разному.
Правила по категориям товаров
Иногда ограничение связано не с весом, а с типом товара.
Например:
- крупногабаритную мебель нельзя отправлять в ПВЗ;
- хрупкий товар доступен только курьером;
- цифровой товар вообще не должен влиять на доставку;
- отдельная категория требует специальной транспортной компании;
- товары со склада поставщика нельзя объединить с собственной доставкой магазина.
Правило может проверять product category, shipping class, tag, attribute или отдельное custom field.
Что делать со смешанной корзиной
Сложность начинается, когда в корзине одновременно товары с разными требованиями.
Допустим, один товар можно отправить в ПВЗ, а второй — только курьером. Показывать ПВЗ для всего заказа уже нельзя.
Здесь нужно определить бизнес-правило:
- выбрать самый строгий способ доставки для всей корзины;
- разделить заказ на shipping packages;
- посчитать несколько доставок;
- запретить несовместимое сочетание;
- предложить клиенту отдельное оформление.
WooCommerce поддерживает shipping packages, но разделение нужно проектировать аккуратно, потому что оно влияет на checkout, налоги, отображение итогов и интеграции.
Как лучше строить расчёт
- АдресWooCommerce определяет подходящую shipping zone
- КорзинаСистема считает вес, subtotal и состав товаров
- УсловияПроверяются категории, classes и дополнительные ограничения
- МетодыНедоступные варианты скрываются, допустимые получают правильный тариф
- CheckoutИтог повторно проверяется сервером перед созданием заказа
Главный принцип: shipping zone выбирает географию, а отдельные правила уточняют доступность и стоимость по составу заказа.
Почему нельзя рассчитывать всё только в JavaScript
Frontend может мгновенно обновлять стоимость и улучшать UX, но итоговый тариф нельзя доверять только данным браузера.
Пользователь может изменить DOM, отправить изменённый запрос или воспроизвести старые checkout-данные.
Поэтому критичные условия должны рассчитываться на сервере:
- вес;
- сумма;
- категории и shipping classes;
- доступность метода;
- финальная стоимость.
Как избежать конфликтов с кешем
Checkout и cart зависят от session и выбранного адреса. Агрессивное кеширование этих страниц может сохранять чужие или устаревшие shipping rates.
При настройке WP Rocket, Cloudflare или другого page cache нужно исключить динамические WooCommerce-страницы и не ломать WooCommerce fragments, Store API и checkout requests.
Сам расчёт доставки также не должен зависеть от закешированного HTML.
Нужно ли ставить отдельный плагин на каждое условие
Для простого магазина готовый conditional shipping plugin может быть нормальным решением.
Проблема начинается, когда для каждой задачи ставится отдельный плагин:
- один управляет бесплатной доставкой;
- второй — весом;
- третий — категориями;
- четвёртый — скрывает методы;
- пятый — меняет стоимость.
Тогда несколько filters WooCommerce начинают изменять один и тот же набор rates в разном порядке. Итог сложно диагностировать.
Если логика уникальная и стабильная, один кастомный модуль часто проще поддерживать, чем цепочка пересекающихся расширений.
Пример комбинированного правила
Допустим, магазин хочет:
- бесплатную курьерскую доставку от 15 000 ₽;
- но только если вес не превышает 10 кг;
- и в корзине нет категории «Крупногабарит»;
- иначе показать платный грузовой тариф;
- для отдельных удалённых зон оставить только транспортную компанию.
Это уже не одно условие. Нужна последовательность проверок и понятный приоритет правил.
Лучше сначала описать её таблицей или схемой, а потом писать код.
Что хранить в настройках, а что в коде
Если менеджер регулярно меняет пороги суммы и стоимость доставки, эти значения лучше вынести в настройки.
Если правило является частью бизнес-архитектуры и меняется редко, его безопаснее держать в коде с понятными комментариями и version control.
Часто удобно разделить:
- в коде — условия и порядок их выполнения;
- в админке — суммы, тарифы, включение отдельных правил;
- в товарах — shipping class или custom field, описывающий логистический тип.
Интеграция с внешней службой доставки
Если тариф приходит из API перевозчика, кастомные правила всё равно могут понадобиться до или после запроса.
Например, можно не отправлять запрос в API для заведомо недоступного способа, применять собственную наценку, ограничивать методы по категории или переключаться на резервный тариф при ошибке внешнего сервиса.
Важно не делать внешний API единственной точкой, из-за которой checkout полностью перестаёт работать.
Что проверить перед запуском
Чек-лист
- Заполнен ли вес у всех товаров, которые участвуют в расчёте.
- Определены ли shipping classes и категории без пересечений.
- Понятно ли, как считать subtotal при скидках.
- Есть ли правила для смешанной корзины.
- Проверены ли налоги и валюта.
- Не кешируются ли cart и checkout.
- Работает ли пересчёт после изменения адреса.
- Проверена ли мобильная версия checkout.
- Есть ли fallback при ошибке внешнего API.
Когда достаточно стандартных зон
Если доставка зависит только от региона и фиксированного тарифа, кастомная разработка не нужна. Сначала лучше нормально настроить штатные зоны доставки WooCommerce.
Отдельная логика оправдана тогда, когда метод или цена зависят от самой корзины и стандартные настройки уже не описывают бизнес-процесс.
Разработка условий доставки WooCommerce
Я дорабатываю WooCommerce под конкретные правила магазина: вес, сумма заказа, категории, shipping classes, несколько складов, API служб доставки и смешанные корзины.
Можно сохранить действующий checkout и добавить только нужную логику без полной переделки магазина.
Подробнее: разработка и доработка WooCommerce. Если уже есть схема тарифов, её можно прислать через форму связи и сразу разбирать как техническое правило.
Обсуждение
Вопросы и комментарии
Можно уточнить детали статьи или поделиться своим опытом. Первый комментарий проходит проверку.