Gravity Forms Limit Dates - Плагин WordPress

Руководство по настройке Gravity Forms Limit Dates для форм с ограничением дат

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

Главная особенность Gravity Forms Limit Dates в том, что он работает не как отдельный календарь бронирования, а как настройка для стандартного поля Date в Gravity Forms. Это удобно для заявок, доставок, консультаций, событий, внутренних запросов и любых форм, где дата является частью более широкой анкеты. Вместо ручного JavaScript в теме вы получаете настройки в редакторе формы и серверную проверку, которая не полагается только на поведение браузера.

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

Какую задачу решает ограничение дат в Gravity Forms

Стандартное поле Date в Gravity Forms умеет принимать дату и показывать календарь, если выбран тип ввода Date Picker. Но само по себе поле даты не всегда знает бизнес-правила сайта. Оно не понимает, что доставка возможна только по будням, заявка на консультацию должна быть минимум через два рабочих дня, дата страхового события не может быть в будущем, а выезд специалиста недоступен во время праздников или закрытых смен.

Gravity Forms Limit Dates добавляет к такому полю слой правил. Администратор формы задает, какие даты можно выбрать, какие дни недели доступны, какие конкретные даты нужно исключить или, наоборот, вернуть в доступный диапазон. Пользователь видит не весь календарь подряд, а только те варианты, которые соответствуют настройке. Если он пытается обойти интерфейс и вручную вписать неподходящее значение, ограничение проверяется при отправке формы.

На практике это закрывает несколько разных задач:

• Запретить выбор прошедших дат для заявок, доставок, бронирований и записи на услугу.
• Ограничить выбор будущим периодом, например ближайшими неделями или текущим учетным периодом.
• Разрешить только определенные дни недели, если команда работает не каждый день.
• Добавить исключения для праздников, внутренних закрытий, технических дней или редких дополнительных смен.
• Связать два поля даты, чтобы дата окончания зависела от даты начала.
• Показывать календарь прямо в форме, если всплывающий календарь неудобен для мобильного сценария.

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

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

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

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

Когда выбор выглядит удачным

Gravity Forms Limit Dates хорошо подходит, если правила выбора дат можно выразить через диапазон, дни недели, исключения, связь с другим полем или небольшой дополнительный snippet. Типичные примеры - доставка не раньше следующего рабочего дня, прием заявок только до определенного периода, форма отпуска в пределах текущего года, бронирование диапазона "заезд - выезд", заявка на мероприятие с несколькими разрешенными датами.

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

Когда стоит подумать о другом инструменте

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

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

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

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

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

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

Платформа и базовая форма

Сначала убедитесь, что форма уже нормально открывается, отправляется и сохраняет запись без Gravity Forms Limit Dates. Добавьте обычное поле Date, выберите тип ввода Date Picker и посмотрите, появляется ли календарь в предпросмотре формы. Документация Gravity Wiz отдельно подчеркивает, что Limit Dates работает с Date Picker. Если вместо него выбран ручной ввод или выпадающие списки даты, ожидаемого поведения в календаре не будет.

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

Часовой пояс и рабочие правила

Для правил вида "текущая дата плюс несколько дней" важен часовой пояс WordPress. Официальная документация Gravity Wiz указывает, что текущая дата для таких ограничений рассчитывается по настройке WordPress, а не по часовому поясу посетителя. Это правильно для бизнеса, который работает в конкретном городе или регионе, но может удивить международную аудиторию.

Перед запуском ответьте себе на вопросы:

• По какому часовому поясу сайт должен считать "сегодня"?
• Нужно ли исключать выходные из минимального срока или календарных дней достаточно?
• Есть ли даты, которые закрыты вручную и должны быть исключениями?
• Должна ли дата окончания зависеть от даты начала?
• Можно ли пользователю вручную вписать дату, или лучше принудительно вести его через календарь?

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

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

После установки нужного perk через Spellbook или текущий механизм Gravity Wiz работа идет в редакторе формы. Не ищите отдельную большую страницу настроек в WordPress: основная логика задается в конкретном поле Date, потому что разные формы и даже разные поля одной формы могут иметь разные правила.

Базовый путь настройки

1. Откройте нужную форму в Gravity Forms.
2. Добавьте поле Date из группы расширенных полей или выберите уже существующее поле даты.
3. Проверьте, что Date Input Type установлен как Date Picker.
4. Откройте вкладку Perks в настройках поля.
5. Задайте Minimum Date, Maximum Date, Days of the Week и Exceptions по вашей задаче.
6. Сохраните форму и проверьте ее в режиме предпросмотра и на реальной странице.

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

Мини-проверка после включения

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

Проверка результата: если запрещенную дату нельзя выбрать мышью, но ее можно набрать вручную и отправить без ошибки, настройка считается неполной. Для Gravity Forms Limit Dates ожидается серверная проверка ограниченной даты.

Подробная настройка поля даты после установки

Самый полезный раздел в работе с Gravity Forms Limit Dates - не "где включить", а как выбрать правильную комбинацию настроек. У поля даты есть несколько независимых уровней: нижняя граница, верхняя граница, разрешенные дни недели, исключения, поведение inline-календаря и проверки при отправке. Если смешать их без плана, календарь может выглядеть правильно только в одном сценарии и ломаться в другом.

Минимальная дата: откуда начинается доступный период

Minimum Date отвечает за самую раннюю дату, которую пользователь может выбрать. В документации описаны три практичных источника: конкретная дата, текущая дата и другое поле даты. Конкретная дата подходит для разовых событий и закрытых кампаний. Текущая дата нужна для заявок "не раньше сегодня" или "не раньше чем через несколько дней". Другое поле даты нужно для связки начала и окончания периода.

Для типовой заявки на доставку чаще всего используют Current Date с модификатором. Например, если команде нужен запас на обработку, минимальная дата может быть "текущая дата плюс два рабочих дня". В интерфейсе это выражается через выбор текущей даты и Date Modifier, который добавляет дни, недели, месяцы, годы или рабочие дни в зависимости от вашей логики.

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

Максимальная дата: где заканчивается окно выбора

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

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

Дни недели: быстрый способ убрать лишние варианты

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

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

Исключения: точечные закрытия и редкие разрешения

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

Официальная документация отмечает важное ограничение: исключения не могут выходить за пределы минимальной и максимальной даты. Это логично. Исключение уточняет доступность внутри рамки, но не расширяет сам диапазон. Если вы добавили разрешенную дату, а она не появилась в календаре, сначала проверьте, не находится ли она раньше Minimum Date или позже Maximum Date.

Inline-календарь: когда он лучше всплывающего

Enable Inline Date Picker показывает календарь прямо в форме, а не только после клика по полю. Такой режим полезен, когда дата является центральным действием: запись на прием, выбор даты доставки, регистрация на событие. Пользователь сразу видит доступные дни и не тратит время на открытие всплывающего календаря.

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

Что лучше не трогать без причины

Не меняйте одновременно формат даты, кастомные скрипты календаря, оптимизацию JavaScript и ограничения Limit Dates. Если появится ошибка, будет трудно понять источник. Сначала настройте правила на обычном поле, потом подключайте стили, popup, кеш и дополнительные сценарии.

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

Связанные поля даты: начало, окончание и зависимые диапазоны

Одна из самых ценных возможностей Gravity Forms Limit Dates - зависимость одного поля даты от другого. Она нужна для периодов: аренда, отпуск, проживание, временный доступ, выезд и возврат, начало и окончание мероприятия. Вместо того чтобы вручную объяснять пользователю "выберите дату окончания после даты начала", можно связать поля так, чтобы второй календарь сразу учитывал первый выбор.

Как работает связка Start Date и End Date

В поле окончания в качестве Minimum Date выбирают другое поле даты - поле начала. После выбора первой даты минимальная дата во втором поле сдвигается. Если нужно, добавляют модификатор: например, дата окончания должна быть минимум на один день позже начала. Для обратного ограничения можно использовать максимальную дату первого поля, если логика формы требует не позволять старт позже уже выбранного конца.

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

Где связка требует особой осторожности

Связанные поля хорошо работают для простых диапазонов, но становятся сложнее, если внутри диапазона есть закрытые даты. Например, пользователь выбирает заезд и выезд, а между ними есть дата, которая недоступна. В официальной snippet-библиотеке Gravity Wiz есть отдельные решения для таких случаев, включая блокировку зарезервированных диапазонов и предотвращение исключений внутри связанного периода. Это уже не базовая настройка в два клика, а расширение под конкретную логику.

Перед запуском такого сценария сформулируйте правило не словами "как в отеле", а в виде проверки:

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

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

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

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

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

Цель - поле "Желаемая дата доставки" должно разрешать только рабочие дни после минимального срока подготовки. В форме уже должны быть имя, телефон или email, адрес доставки и поле Date с типом Date Picker. Если форма отправляет уведомления менеджеру, сначала проверьте, что уведомление работает без ограничений даты.

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

1. Откройте поле даты в редакторе формы и убедитесь, что выбран Date Picker.
2. На вкладке Perks установите Minimum Date как Current Date.
3. Добавьте модификатор с запасом на обработку. Если нужна именно рабочая логика, используйте рабочие дни, а не обычные календарные дни.
4. В Days of the Week оставьте только рабочие дни, когда доставка реально выполняется.
5. В Exceptions добавьте закрытые даты: инвентаризация, праздники, дни без курьеров.
6. Сохраните форму и откройте публичную страницу в режиме обычного посетителя.

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

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

Проверьте форму как пользователь, а не как администратор. Выберите ближайшую доступную дату, отправьте тестовую заявку, проверьте запись в Gravity Forms и уведомление. Затем попробуйте ввести закрытую дату вручную. Ожидаемое поведение - форма не должна принять значение, которое нарушает правило.

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

Нюанс с поздними заказами

Для доставки часто есть отсечка по времени: заказ после определенного часа уже не должен попадать в минимальный срок "завтра". Базовая настройка Current Date не всегда выражает такую логику. В snippet-библиотеке Gravity Wiz есть пример, который сдвигает минимальную дату на следующий день после заданного часа, используя фильтр gpld_limit_dates_options_FORMID_FIELDID.

Ниже - адаптированный учебный пример. Его стоит использовать только после проверки официального snippet и замены идентификаторов формы и поля. Вставляйте такой код через Code Snippets, Code Chest или небольшой site-specific plugin, а не в ядро WordPress и не в файлы плагина.

<?php
// Пример: после 17:00 минимальная дата доставки сдвигается на завтра.
// Замените 123 на ID формы, а 4 на ID поля Date.
add_filter( 'gpld_limit_dates_options_123_4', function( $options ) {
    $cutoff_hour  = 17;
    $current_time = new DateTime( wp_timezone_string() );
    $cutoff_time  = ( new DateTime( wp_timezone_string() ) )->setTime( $cutoff_hour, 0 );

    if ( $current_time > $cutoff_time ) {
        $tomorrow = new DateTime( 'tomorrow midnight', $current_time->getTimezone() );
        $options['minDate'] = wp_date( 'm/d/Y', $tomorrow->getTimestamp() );
    }

    return $options;
} );

После добавления snippet проверьте форму до и после отсечки. Если результат спорный, временно отключите snippet и убедитесь, что базовые настройки Limit Dates снова работают. Такой откат быстрый и безопасный, потому что вы не меняли файлы плагина.

Идеи применения: от заявок до внутренних процессов

Ограничение дат полезно не только для доставки. Чем точнее вы описываете правило, тем меньше ручных уточнений получает команда после отправки формы. Ниже - несколько сценариев, где Gravity Forms Limit Dates дает практический эффект без превращения формы в отдельную систему бронирования.

Заявки на консультацию или выезд специалиста

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

Формы мероприятий и регистрации

Для события с несколькими возможными датами можно использовать диапазон и исключения, а для редких разрешенных дат - обратную логику через официальный snippet "disable all dates and set enabled dates via exceptions". Такой вариант удобен, если доступных дат мало и их легче перечислить, чем закрывать все остальные.

Внутренние заявки и кадровые процессы

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

Периоды аренды и временного доступа

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

Как проверить результат на сайте, а не только в предпросмотре

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

Проверка выбора мышью и ручного ввода

Откройте календарь и попробуйте выбрать дату, которая должна быть недоступна. Затем вручную введите такую дату в поле, если поле принимает текст. Для Limit Dates важно, чтобы ошибка появлялась при отправке формы, потому что клиентская проверка может только подсказать пользователю, а окончательное решение принимает сервер.

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

Проверка часового пояса

Если используется Current Date, откройте настройки WordPress и убедитесь, что часовой пояс соответствует бизнесу. Затем проверьте форму на границе дня, если это важно для вашего процесса. Для международных сайтов заранее решите, что важнее: локальная дата посетителя или рабочая дата компании. Плагин опирается на часовой пояс WordPress для текущей даты, и это нужно учитывать в тексте формы.

Проверка после кеша и оптимизации

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

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

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

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

Календарь не появляется у поля даты

Симптом: поле выглядит как обычный текстовый ввод, календарь не открывается, настройки Limit Dates не видны в поведении формы.

Возможная причина: поле не использует Date Picker, на странице есть JavaScript-ошибка, форма встроена в popup, который инициализируется после загрузки страницы, или оптимизация скриптов нарушила порядок подключения.

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

Как исправить: вернуть тип Date Picker, временно отключить конфликтующую оптимизацию, исключить страницу формы из объединения скриптов, проверить настройки popup или конструктора. Если после отключения оптимизации календарь ожил, включайте улучшения обратно по одному.

Пользователь может выбрать закрытую дату

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

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

Что проверить: ID поля, вкладку Perks, выбранные дни недели, список исключений, ручной ввод и серверную ошибку после отправки. Если дата выбирается мышью, проблема в конфигурации интерфейса. Если мышью не выбирается, но отправляется вручную, проверьте серверную валидацию и сторонние скрипты.

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

Разрешенная дата стала недоступной

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

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

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

Как исправить: расширить диапазон, убрать лишнее исключение, изменить модификатор или добавить конкретную дату как исключение только если она находится внутри общего диапазона. Не пытайтесь исключением открыть дату за пределами min/max - это ограничение официально описано в документации.

Дата сдвигается не так из-за часового пояса

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

Возможная причина: текущая дата считается по часовому поясу WordPress. Это может отличаться от часового пояса посетителя или от фактического рабочего графика компании.

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

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

Связанные поля ведут себя непредсказуемо

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

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

Что проверить: какое поле указано как источник Minimum Date или Maximum Date, нужен ли модификатор, есть ли исключения внутри диапазона и требуется ли официальный snippet для предотвращения таких периодов.

Как исправить: сначала добиться простой связи "окончание не раньше начала". Затем отдельно решать занятые диапазоны и исключения. Если нужно учитывать предыдущие записи, используйте готовые snippets Gravity Wiz или отдельную систему бронирования, а не случайный фрагмент кода из обсуждения.

Безопасные улучшения и когда лучше не писать код

У Gravity Forms Limit Dates есть официальная snippet-библиотека, и это большой плюс для сложных сценариев. Но snippets нужно применять как точечное расширение, а не как способ заменить продуманную настройку. Если правило можно выразить через Minimum Date, Maximum Date, дни недели и исключения, сначала используйте интерфейс.

Когда snippet оправдан

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

Перед установкой такого кода проверьте источник, дату обновления страницы snippet, комментарии разработчика и способ установки. Для неразработчика лучше использовать менеджер snippets, где код можно быстро отключить. Для агентства безопаснее держать такие правила в отдельном site-specific plugin, чтобы они не потерялись при смене темы.

Когда код лучше не добавлять

Не добавляйте код, если вы не можете объяснить, какое именно правило он меняет. Не используйте фрагменты, которые требуют правки файлов Gravity Forms, Gravity Wiz или темы. Не копируйте старые решения для общего jQuery UI Datepicker, если они не учитывают серверную проверку Gravity Forms. И не ставьте два разных скрипта, которые пытаются управлять одним и тем же полем даты.

Если нужен только внешний вид поля, используйте CSS-селекторы Gravity Forms для Date field и тему формы. Если нужен запрет дат, используйте Limit Dates. Если нужен ресурсный календарь, не маскируйте его сложной цепочкой snippets - выберите инструмент, который умеет работать с ресурсами.

Когда Gravity Forms Limit Dates будет удачным выбором

Gravity Forms Limit Dates стоит использовать, если ваша задача звучит как "разрешить пользователю выбрать только правильную дату в форме Gravity Forms". Плагин закрывает практический набор правил: min/max, текущая дата, модификаторы, дни недели, исключения, связанные поля, inline-календарь, клиентская и серверная проверка. Главное - не пытаться сделать из него систему бронирования ресурсов, если бизнес-логика уже вышла за рамки поля даты.

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

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

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