WooCommerce Order Delivery - Плагин WordPress

Руководство по настройке WooCommerce Order Delivery для доставки и самовывоза

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

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

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

Отдельно важно: плагин работает внутри критической зоны магазина - checkout. Поэтому любые изменения нужно сначала повторять на тестовом заказе, а для действующего магазина желательно использовать staging-копию. Хорошая настройка доставки проверяется не в админке, а полным путем клиента: корзина, способ доставки, дата, слот, оплата, письмо и карточка заказа.

Какую задачу закрывает плагин в реальном магазине

На практике магазину редко достаточно обычной фразы "доставка 2-3 дня". Если вы печете торты, продаете цветы, доставляете продукты, отдаете заказы из пункта самовывоза или готовите наборы под конкретную дату, вам нужно управлять обещанием. Клиент хочет знать, когда он получит заказ, а команда магазина должна видеть, какие заказы нужно собрать и когда их передать.

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

Выбор даты клиентом

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

Показ расчетной даты

Расчетная дата удобнее для магазинов, где клиент не выбирает время, но должен понимать ожидание: склад собирает заказ, затем заказ уходит выбранным способом доставки. В этом случае календарь может быть лишним, а информативный блок с ожидаемой датой снижает число вопросов в поддержку.

Доставка и самовывоз как разные процессы

Важная особенность актуальной логики плагина - доставка и самовывоз могут иметь отдельные расписания. Это не мелочь. У доставки могут быть вечерние окна, у самовывоза - дневные часы, а у подготовки заказа - общий cut-off, после которого заказ считается принятым уже на следующий рабочий цикл. Если настроить оба сценария одинаково, магазин быстро столкнется с конфликтами: клиент выбрал самовывоз в слот, когда точка уже закрыта, или доставку в день, когда курьерская зона не обслуживается.

Условно плагин можно представить как слой между тремя вещами:

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

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

Кому подходит WooCommerce Order Delivery, а кому лучше смотреть другое решение

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

Хорошие сценарии

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

• У магазина есть рабочие дни подготовки, и заказы после определенного времени должны переноситься на следующий цикл.
• Есть разные окна доставки или самовывоза, например утро, день, вечер или интервалы с частотой 30 или 60 минут.
• Нужно ограничивать количество заказов на день или временной интервал, чтобы не перегружать производство.
• Для разных способов доставки нужны разные диапазоны, например экспресс и стандартная доставка.
• Команда хочет видеть дату доставки или самовывоза в списке заказов, письмах и карточке заказа.

Когда плагин может быть лишним

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

Еще один случай - магазин с очень простым процессом, где достаточно текста в описании способа доставки. Например, если все заказы отправляются "в течение 1-2 рабочих дней" и клиенту нечего выбирать, календарь может добавить лишний шаг. В таком магазине лучше начать с расчетной даты или с понятного описания способа доставки, а выбор даты включать только при реальной операционной необходимости.

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

Что проверить перед установкой на WooCommerce-сайт

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

Часовой пояс WordPress

Первое, что нужно проверить, - часовой пояс сайта в Settings - General. Плагин использует время магазина для расчета cut-off, локализации дат и доступности. Если сайт оставлен на UTC или на неподходящем городе, правило "после 15:00 переносить подготовку на следующий день" будет работать не так, как думает администратор.

Проверка простая: сравните время в админке WordPress с фактическим временем магазина. Если магазин работает в одном регионе, выбирайте город или часовой пояс этого региона, а не абстрактное смещение. Если магазин международный, зафиксируйте, по какому времени считается подготовка заказа, и объясните это команде.

Способы доставки и самовывоза

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

Проверьте минимум:

• Есть ли shipping zones для основных регионов или городов.
• Созданы ли методы доставки, которые клиент выбирает на checkout.
• Настроен ли локальный самовывоз, если магазин предлагает pickup.
• Понятно ли, какие методы должны видеть календарь, а какие нет.

Тип checkout: блок или классический shortcode

WooCommerce поддерживает современный Checkout block и классический checkout через [woocommerce_checkout]. Для Order Delivery это важно, потому что часть настроек позиции поля на странице относится к классическому checkout, а в block checkout расположение может быть ограничено архитектурой блока. Поэтому перед настройкой решите, какой checkout используется на сайте, и не пытайтесь диагностировать "сломанное расположение" там, где сам тип checkout не дает свободно менять позицию.

Кеш, оптимизация и checkout

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

Тестовая среда

Для действующего магазина безопаснее сначала настроить плагин на staging-копии. Это особенно важно, если у вас уже есть кастомные поля checkout, нестандартная тема, checkout-конструктор, подписки, дополнительные сборы, плагины счетов или HPOS. Проверка на тестовой копии экономит больше времени, чем быстрый запуск на рабочем сайте с последующим разбором заказов, оформленных с неверной датой.

Установка и первичная проверка после активации

Установка выполняется как у обычного Woo Marketplace-расширения. Если сайт подключен к WooCommerce.com и используется WooCommerce.com Update Manager, расширение можно установить из админки. Если автоматическая установка недоступна, загрузите ZIP-файл из аккаунта WooCommerce.com и установите его через Plugins - Add New Plugin - Upload Plugin. После установки нажмите Activate.

Сразу после активации не переходите к сложным слотам. Сначала проверьте, что настройки появились в правильном месте и что плагин видит базовую конфигурацию магазина. В актуальной документации основной путь указан как WooCommerce - Settings - Delivery & Pickup Dates. В старых материалах или после обновления вы можете встретить похожие названия вкладок, поэтому ориентируйтесь на документацию вашей версии и на фактические пункты в админке.

Минимальная проверка без сложных правил

1. Откройте WooCommerce - Settings - Delivery & Pickup Dates.
2. Выберите, что показывать клиентам: доставку, самовывоз или оба варианта.
3. Решите, должен ли клиент выбирать дату или видеть расчетную дату.
4. Сохраните настройки через Save Changes.
5. Откройте тестовый товар, добавьте его в корзину и перейдите к checkout.
6. Проверьте, появилось ли поле даты, временной интервал или расчетная информация.

На этом этапе цель не в том, чтобы сделать идеальную настройку. Цель - убедиться, что расширение подключилось, checkout не падает, базовое поле отображается, а способ доставки выбран. Если уже на этом шаге поле не появляется, не настраивайте дальше time frames и fees. Сначала разберите базовую видимость.

Что должно быть видно администратору

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

Проверьте заказ в WooCommerce - Orders. Найдите колонки или фильтры, связанные с shipping date и delivery/pickup date, а затем откройте сам заказ. Если дата не попала в заказ, проблема не в письме, а в сохранении данных или в сценарии checkout. Если дата в заказе есть, но не пришла в письме, тогда диагностируйте шаблоны писем и сторонние плагины email.

Настройка выбора даты, расчета и обязательности поля

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

Доставка, самовывоз или оба варианта

В настройке Show delivery/estimates for выберите, для чего показывать даты: только delivery, только pickup или оба сценария. Если магазин действительно поддерживает и доставку, и самовывоз, лучше не сводить их к одному расписанию. У них обычно разные ограничения: доставка зависит от курьера и зоны, самовывоз - от часов точки выдачи и подготовки заказа.

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

Клиент выбирает дату или видит оценку

Настройка Customers should определяет поведение: клиент выбирает дату или видит оценочную информацию. Для локальной доставки и самовывоза обычно нужен выбор. Для обычной отправки перевозчиком часто достаточно estimates. Если магазин использует несколько shipping methods, расчетная дата может быть честнее: клиент выбирает метод, а плагин показывает диапазон, рассчитанный по lead time, рабочим дням и delivery ranges.

Когда делать поле обязательным

Поле даты стоит делать обязательным, когда без него команда не сможет выполнить заказ. Например, доставка цветов без даты бессмысленна. Но если дата нужна только как дополнительное пожелание, обязательность может снижать конверсию. В режиме выбора даты настройка Picking a date is позволяет сделать поле required или optional.

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

Дата по умолчанию

Use a default date может автоматически подставлять первую доступную дату. Это удобно, когда большинство клиентов соглашается на ближайший вариант. Но для заказов к событию - букет к празднику, торт к дате, самовывоз в конкретный день - автоподстановка может привести к ошибкам: клиент не заметит поле и оставит случайную дату. Для таких сценариев лучше заставить клиента осознанно выбрать день.

Глубина календаря

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

Мини-итог этого раздела: сначала выберите модель обещания, затем обязательность, затем глубину календаря. Не начинайте с time frames, пока не понятен режим: "клиент выбирает" или "магазин показывает оценку".

Picking: как подготовка заказа влияет на доступные даты

Раздел Picking отвечает за то, когда заказ можно считать подготовленным. Это не то же самое, что день доставки. Магазин может принять заказ сегодня, собрать завтра, а доставить послезавтра. Если эти этапы смешать, календарь будет показывать слишком ранние даты.

Order picking cut-off time

Order picking cut-off time задает время, после которого текущий день уже не считается рабочим днем подготовки для нового заказа. Например, если команда принимает заказы в работу до 15:00, заказ после этого времени должен перейти в следующий доступный цикл подготовки. Это особенно важно для same-day и next-day сценариев.

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

Order picking days

Order picking days - дни, когда магазин реально готовит заказы. Только эти дни учитываются в lead time. Если склад работает с понедельника по пятницу, а доставка выполняется в субботу, суббота может быть delivery day, но не picking day. Это нормальная ситуация: заказ готовят в будни, доставляют в другой день.

Для отдельных дней можно задавать свой cut-off. Это полезно, когда в пятницу команда закрывает сборку раньше, чем в остальные дни, или когда в день самовывоза подготовка заканчивается до обеда. Если поле cut-off у конкретного дня пустое, применяется общее значение.

Lead time in days

Lead time in days показывает, сколько рабочих дней подготовки нужно до первого возможного выполнения. Важно понимать, что учитываются именно enabled picking days, а не все календарные дни. Если lead time равен 1, но завтра не является днем подготовки, расчет перескочит дальше.

Типовая настройка для магазина с подготовкой на следующий рабочий день

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

• Order picking days: рабочие дни команды.
• Order picking cut-off time: время, после которого новый заказ уже не попадает в текущий цикл.
• Lead time in days: минимальное число рабочих дней подготовки.
• Disable specific dates: праздники, инвентаризация, закрытые дни.

Проверка результата: оформите тестовый заказ до cut-off и после cut-off. Разница в доступных датах должна быть видна на checkout. Если календарь показывает одинаковые даты, проверьте часовой пояс WordPress и то, сохранены ли picking days.

Отключение дат подготовки

Кнопка Disable specific dates нужна для дней, когда заказы не готовятся: праздники, закрытие склада, переезд, инвентаризация. Эти даты исключаются из расчетов подготовки и не должны считаться рабочими. Не используйте отключение дат как замену расписанию. Постоянные выходные удобнее задавать через weekdays, а точечные исключения - через disabled dates.

Проверка после настройки Picking: выберите один реальный сценарий заказа, посчитайте дату вручную и сравните с checkout. Если ручной расчет и календарь расходятся, сначала ищите проблему в часовой зоне, cut-off или lead time, а не в delivery scheduling.

Delivery Scheduling и Pickup Scheduling: дни, интервалы, лимиты и fees

Когда подготовка заказа настроена, можно переходить к расписанию доставки и самовывоза. Эти разделы определяют, когда уже подготовленный заказ можно доставить или выдать. Плагин применяет их поверх расчета Picking: сначала заказ должен быть готов, затем должен существовать подходящий день, диапазон и time frame.

Дни доставки и самовывоза

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

После изменения доступных дней нажмите Save Changes до добавления time frames. В документации отдельно подчеркивается этот порядок: если дни еще не сохранены, при переходе в редактор интервалов часть изменений может не попасть в расчет.

Time frames: один интервал или частота

Time frames позволяют дать клиенту временное окно. У интервала есть title, starting time, ending time, frequency, order limit, shipping methods, fee amount и привязка к дням. Если frequency не задана, интервал работает как одно окно. Если выбрать 30 или 60 минут, плагин разделит диапазон на отдельные слоты.

Пример: окно 10:00-12:00 с frequency 60 minutes превращается в два слота: 10:00-11:00 и 11:00-12:00. Если задан order limit, он применяется к каждому созданному слоту. Это удобно, когда у команды одинаковая пропускная способность в каждом часовом окне.

Order limit

Order limit защищает от перепродажи слота. Значение 0 означает отсутствие лимита. Для локальной доставки лучше не оставлять лимит бесконечным, если физически команда не может выполнить любое количество заказов. Подберите значение из реальной нагрузки: количество курьеров, средняя длительность маршрута, время подготовки, наличие сборщиков.

Shipping methods

Ограничение по shipping methods помогает показывать разные слоты для разных способов доставки. Например, экспресс-доставка может иметь короткие окна и дополнительную fee, а стандартная - только дневной диапазон. Если в день есть time frames, но ни один из них не подходит выбранному shipping method или все слоты заполнены, день может стать недоступным на checkout.

Fee amount и понятная подпись

Fee amount позволяет добавить фиксированную доплату за конкретный день или слот. Используйте это аккуратно. Доплата должна быть понятна клиенту: срочный слот, вечерняя доставка, доставка в выходной. Если label не объясняет причину, клиент воспринимает fee как скрытую наценку.

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

Advanced delivery ranges

Advanced delivery ranges нужны, когда разные shipping methods имеют разные диапазоны. Например, premium delivery может быть доступна раньше, а standard delivery - позже. Диапазон задается как количество дней после первой даты, рассчитанной через Picking. Это не замена lead time, а следующий слой правила.

Порядок ranges важен. Более специфичные варианты должны стоять выше общих, иначе общий диапазон может перехватить метод раньше. Думайте о ranges как о правилах приоритета: сначала точное правило для конкретного shipping method, затем fallback.

Delivery instructions и pickup instructions

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

Мини-итог: Delivery Scheduling и Pickup Scheduling должны отражать реальные операционные окна. Если настройка кажется красивой, но команда не сможет ее выполнить, ее нельзя показывать клиенту.

Сценарий "заказ к удобному времени": практический пример настройки

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

Цель

Клиент выбирает доставку или самовывоз на checkout. Для доставки доступны вечерние окна с лимитом заказов, для самовывоза - дневные окна. Заказы после cut-off не должны попадать в слишком ранние даты. В карточке заказа администратор видит дату, слот и тип получения.

Подготовка

Перед настройкой должны быть готовы:

• Рабочий WooCommerce checkout с тестовым товаром.
• Способы доставки и самовывоза в shipping zones.
• Правильный часовой пояс WordPress.
• Тестовая платежная настройка или безопасный способ оформить заказ без реальной оплаты.

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

1. В Delivery & Pickup Dates выберите показ дат для доставки и самовывоза.
2. Включите режим, где клиент выбирает дату, а не только видит оценку.
3. Сделайте дату обязательной, если заказ без даты нельзя выполнить.
4. В Picking включите дни подготовки и задайте cut-off.
5. Укажите lead time, который соответствует реальному времени сборки.
6. В Delivery Scheduling включите дни доставки и добавьте вечерние time frames.
7. Для каждого time frame задайте order limit и при необходимости fee.
8. В Pickup Scheduling включите дни самовывоза и добавьте отдельные дневные интервалы.
9. Сохраните настройки и откройте checkout в режиме обычного клиента.

Проверка

Проверка должна имитировать реальный путь. Добавьте товар в корзину, выберите способ доставки, посмотрите доступные даты и слоты. Затем смените способ на самовывоз и убедитесь, что набор дат и интервалов изменился. Оформите тестовый заказ, откройте WooCommerce - Orders и проверьте дату в списке заказов и в карточке заказа.

Нюанс, который часто ломает сценарий

Если после выбора другого shipping method календарь не меняется, причина часто не в самом календаре, а в связке time frame и shipping methods. Проверьте, привязан ли нужный time frame к выбранному способу доставки, нет ли заполненного лимита, сохранены ли дни доставки и не отключена ли дата через disabled dates. Если используется checkout-плагин, временно проверьте сценарий на стандартном checkout или изучите документацию совместимости.

Где смотреть результат: checkout, письма, заказы и операционная работа

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

Checkout

На checkout проверьте не только наличие поля, но и поведение. Измените shipping method, адрес, способ самовывоза, состав корзины. Если выбранный метод должен скрывать time frame, он должен исчезнуть. Если дата обязательна, заказ без даты должен останавливаться. Если слот заполнен, он не должен оставаться доступным для нового заказа.

Письма и личный кабинет

После оформления заказа выбранная дата и time frame должны быть понятны клиенту. Проверьте письмо о заказе и страницу заказа в аккаунте. Если магазин редактирует письма через отдельный плагин или шаблон, убедитесь, что delivery/pickup details не были удалены кастомизацией.

Список заказов и фильтры

В админке важно видеть, какие заказы нужно готовить и когда. Документация описывает колонки и фильтры по shipping date и delivery/pickup date. Используйте их как операционный инструмент: отфильтруйте заказы на ближайшее окно, проверьте статус, подготовьте список сборки.

Редактирование заказа

Если клиент звонит и просит изменить дату, администратор должен понимать, где это делается. В карточке заказа ищите блок delivery или pickup details. После изменения сохраните заказ и проверьте, как новая дата отображается клиенту. Не меняйте дату в произвольном заметочном поле, если плагин хранит ее в своем блоке: команда может увидеть одно значение, а клиент - другое.

Мини-проверка перед запуском: один тестовый заказ должен пройти весь путь от checkout до письма и списка заказов. Если результат не виден хотя бы в одном месте, запускать настройку на поток заказов рано.

Особые режимы: самовывоз, подписки, tips и совместимость checkout

Базовый календарь - только часть возможностей. В WooCommerce Order Delivery есть режимы, которые стоит включать не автоматически, а по задаче магазина. Они полезны, но добавляют условия в checkout, поэтому требуют отдельной проверки.

Самовывоз с отдельным расписанием

Если магазин предлагает pickup, настройте его не как "доставку без курьера", а как отдельный процесс. У самовывоза могут быть свои дни, свои time frames, свой текст инструкций и свой лимит. После перехода на отдельные расписания доставки и самовывоза старые настройки, где pickup использовал delivery schedule, нужно внимательно пересмотреть.

Если магазин обновлялся с более старой конфигурации, не рассчитывайте на полностью автоматическое разделение. В документации по migration прямо объясняется, что автоматическое распределение старых pickup-правил может быть небезопасным, потому что у магазинов разные схемы лимитов и shipping method rules. Поэтому после обновления проверьте оба расписания вручную.

WooCommerce Subscriptions

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

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

Tips на checkout

Блок tips позволяет предложить чаевые для доставки или самовывоза. Он добавляет сумму как fee в заказ. Включайте его только там, где это уместно для бизнес-модели: локальная доставка, курьерская передача, сервисная услуга. Для обычной отправки складами или почтовыми службами tips могут выглядеть странно.

При настройке tips проверьте тип: процент или фиксированная сумма, presets, возможность custom amount, tax status и ограничение по shipping methods. Если tips показываются только для локальной доставки, привяжите их к нужному методу. После тестового заказа убедитесь, что fee корректно попадает в итог и не конфликтует с налогами.

CheckoutWC, Fluid Checkout и другие checkout-решения

Официальная документация Kestrel упоминает совместимость с CheckoutWC. У Fluid Checkout есть отдельная статья о работе с Order Delivery, где описаны integration options, inline calendar view и хуки для положения блока. Это хороший пример того, как диагностировать сторонний checkout: искать не общий совет "отключите тему", а конкретную страницу совместимости.

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

Производительность, HPOS и безопасные улучшения без правки плагина

Так как расширение работает с заказами, checkout и фильтрами, его поведение зависит от общей архитектуры WooCommerce. На больших магазинах стоит учитывать HPOS, кеш, шаблоны checkout и сторонние оптимизаторы. Но это не значит, что нужно править код плагина.

HPOS и заказы

WooCommerce High-Performance Order Storage хранит заказы в отдельных таблицах и меняет способ работы с order data. На странице продукта WooCommerce указано, что расширение совместимо с HPOS, но на конкретном сайте все равно нужно проверять весь набор плагинов. Если в WooCommerce - Settings - Advanced - Features WooCommerce показывает несовместимые расширения, не включайте изменения вслепую.

Практическая проверка проста: включить compatibility mode на staging, синхронизировать заказы, оформить тестовый заказ с датой доставки, убедиться, что дата видна в списке заказов, фильтрах, карточке заказа и письме. Если проблема появляется только при HPOS, фиксируйте ее для поддержки разработчика с точными шагами.

Кеш checkout

Checkout, cart и account должны быть исключены из page cache. Иначе клиент может увидеть устаревшие слоты или некорректное состояние корзины. Если плагин кеша поддерживает отдельные исключения для WooCommerce, используйте их. Если календарь ведет себя странно только для незалогиненных пользователей, проверьте кеш в первую очередь.

Безопасное CSS-улучшение для читаемости блока

Если поле даты или блок delivery details выглядит тесно в вашей теме, можно добавить небольшой CSS через Appearance - Customize - Additional CSS или через дочернюю тему. Этот snippet не полагается на внутренние классы плагина: он аккуратно улучшает общие поля в checkout и не меняет логику оформления заказа.

/* Улучшает читаемость полей даты и времени в блоках checkout.
   Перед публикацией проверьте на тестовом заказе и мобильной ширине. */
.woocommerce-checkout .form-row input[type="date"],
.woocommerce-checkout .form-row input[type="time"],
.woocommerce-checkout .form-row select {
  min-height: 44px;
}

.woocommerce-checkout .form-row label {
  line-height: 1.35;
}

Проверка: откройте checkout на мобильной и десктопной ширине, выберите дату, смените shipping method и оформите тестовый заказ. Откат: удалите CSS и очистите кеш. Если тема использует собственные компоненты checkout, такой общий CSS может не затронуть нужный блок - тогда лучше корректировать стили темы, а не угадывать внутренние селекторы плагина.

Что не стоит делать

Не редактируйте файлы WooCommerce Order Delivery напрямую. Не вставляйте непроверенные PHP snippets с выдуманными hook names. Не переносите поле даты скриптом, если checkout-плагин уже предоставляет штатную интеграцию. Любое вмешательство в checkout должно сохранять валидацию, пересчет totals и сохранение данных заказа.

Частые проблемы и диагностика WooCommerce Order Delivery

Диагностику лучше вести от простого к сложному. Сначала проверьте базовую видимость поля и часовой пояс, затем shipping methods, затем time frames, затем checkout-совместимость и кеш. Не меняйте сразу несколько настроек, иначе будет трудно понять, что именно исправило проблему.

Поле даты не появляется на checkout

Симптом: настройки включены, но клиент не видит delivery или pickup date.

Возможные причины: не выбран режим показа дат, отсутствует подходящий shipping method, checkout использует блоковую структуру с ограниченной позицией, поле скрыто темой или checkout-плагином, выбран сценарий estimates вместо date picker.

Что проверить: включен ли нужный вариант в Show delivery/estimates for, выбран ли shipping method на checkout, сохранены ли настройки, не скрыт ли блок после смены доставки. Для стороннего checkout найдите страницу совместимости или временно проверьте стандартный checkout.

Как исправить: начните с минимальной настройки delivery only без time frames, сохраните, проверьте стандартный товар и стандартный способ доставки. Если поле появилось, возвращайте сложные правила по одному.

Календарь показывает слишком ранние даты

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

Возможные причины: неверный часовой пояс WordPress, пустой cut-off, слишком маленький lead time, включены лишние picking days, disabled dates не добавлены.

Что проверить: время магазина в Settings - General, Order picking cut-off time, per-day cut-off, Lead time in days, список рабочих дней подготовки.

Как исправить: настройте Picking как отдельный этап подготовки. Оформите один заказ до cut-off и один после cut-off. Если расчет изменился, проблема была в подготовке, а не в delivery days.

Слоты перепродаются или не исчезают после заполнения

Симптом: магазин получает больше заказов на один интервал, чем может выполнить.

Возможные причины: Order limit равен 0, лимит задан не на тот time frame, frequency создает отдельные подслоты с отдельными лимитами, тестовые заказы не учитываются так, как вы ожидаете.

Что проверить: конкретный time frame, его frequency, лимит, привязку к дням и shipping methods. Проверьте не общий день, а именно слот, который выбирает клиент.

Как исправить: задайте реалистичный лимит на time frame или на каждый frequency-слот. Проверьте несколькими тестовыми заказами, что после достижения лимита слот больше не предлагается.

Дата меняется не так, как ожидалось при смене способа доставки

Симптом: при выборе standard или express клиент видит одинаковые даты, хотя правила должны отличаться.

Возможные причины: advanced ranges стоят в неправильном порядке, time frames не привязаны к shipping methods, default range перехватывает все методы, checkout не пересчитывает блок после смены метода.

Что проверить: порядок advanced delivery ranges, метод доставки в каждом range, shipping method rules в time frames, очистку кеша checkout.

Как исправить: расположите более специфичные ranges выше общих. Затем оформите тестовый заказ с каждым shipping method и сравните earliest и latest dates.

Данные есть в checkout, но команда не видит их в заказах

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

Возможные причины: заказ не прошел полный checkout, кастомный email-шаблон удаляет данные, сторонний order management plugin меняет отображение колонок, проблема проявляется только при HPOS или кастомном checkout.

Что проверить: карточку заказа, список заказов, письмо клиенту, режим хранения заказов, активные шаблоны писем. Сравните стандартное письмо WooCommerce и кастомное письмо.

Как исправить: сначала подтвердите, сохраняется ли дата в метабоксе заказа. Если сохраняется, исправляйте отображение письма или колонок. Если не сохраняется, возвращайтесь к checkout-валидации и конфликтам.

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

Симптом: pickup показывает старые delivery slots или delivery использует интервалы самовывоза.

Возможные причины: магазин раньше использовал общие правила для local pickup, а после перехода на отдельные расписания их нужно разделить вручную.

Что проверить: настройки Delivery Scheduling и Pickup Scheduling, старые time frames, ranges, order limits и привязки к shipping methods.

Как исправить: разделите расписания вручную: удалите pickup-интервалы из delivery, создайте их в pickup, пересмотрите лимиты и ranges. Делайте это на staging, затем повторите тестовые заказы для обоих сценариев.

Когда WooCommerce Order Delivery будет удачным выбором

WooCommerce Order Delivery стоит использовать, когда магазин готов формализовать свое обещание клиенту: какие дни доступны, сколько времени занимает подготовка, какие слоты выдерживает команда, где действует самовывоз и какие shipping methods должны иметь отдельные ranges. Это не просто визуальный календарь, а механизм, который связывает checkout с операционной работой.

Перед запуском пройдите короткий итоговый чек-лист: часовой пояс WordPress, shipping methods, режим выбора или estimates, Picking, delivery/pickup scheduling, time frames, order limits, тестовый заказ, письмо клиенту, список заказов и фильтры. Если каждый пункт проверен, можно переходить к рабочему использованию.

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

Лучший результат получается тогда, когда календарь не обещает больше, чем может выполнить магазин. Настройте меньше дат, но надежнее; добавьте лимиты, если есть физическое ограничение; разделите delivery и pickup, если процессы разные; проверяйте каждое изменение полным тестовым заказом. Тогда плагин помогает не только checkout, но и всей цепочке выполнения заказа.