Gravity Forms Limit Dates - WordPress Plugin

Guide to Configuring Gravity Forms Limit Dates for Date-Restricted Forms

Gravity Forms Limit Dates is useful when the standard Gravity Forms date field is no longer enough: users should not be able to pick weekends, past dates, blocked days, delivery dates that are too soon, or an end date that comes before the start date. This guide focuses on a practical setup workflow rather than a product overview: how to prepare the form, where to find the settings, how to choose the minimum and maximum date, how to link two fields, how to verify the result, and what to do if the calendar behaves differently than expected.

The key thing about Gravity Forms Limit Dates is that it does not function as a standalone booking calendar. Instead, it extends the standard Date field in Gravity Forms. That makes it useful for requests, deliveries, consultations, events, internal forms, and any workflow where the date is just one part of a broader form. Instead of maintaining custom JavaScript in your theme, you get field-level settings in the form editor plus server-side validation that does not rely only on browser behavior.

The examples below do not cover purchasing, license keys, or workarounds. This guide assumes Gravity Forms and the required perk are already available on the site. The goal is to help you configure the product safely, understand its limits, and decide whether it fits your form.

What problem date restrictions solve in Gravity Forms

The standard Date field in Gravity Forms can accept a date and display a calendar when the input type is set to Date Picker. But on its own, the field does not understand your site's business rules. It does not know that deliveries are available only on weekdays, consultation requests must be scheduled at least two business days in advance, the date of an insurance incident cannot be in the future, or technician visits are unavailable on holidays or during closed shifts.

Gravity Forms Limit Dates adds a rules layer to that field. The form admin decides which dates can be selected, which weekdays are allowed, which specific dates must be excluded, and which dates should be re-enabled within the allowed range. Instead of seeing every date in the calendar, the user sees only the options that match the configuration. If someone tries to bypass the interface and manually enter an invalid value, the restriction is still checked when the form is submitted.

In practice, that helps solve several different tasks:

• Block past dates for requests, deliveries, bookings, and service appointments.
• Limit selection to a future window, such as the next few weeks or the current reporting period.
• Allow only specific weekdays if the team does not operate every day.
• Add exceptions for holidays, internal closures, maintenance days, or occasional extra shifts.
• Link two date fields so the end date depends on the start date.
• Display the calendar directly in the form when a popup calendar is inconvenient on mobile.

It is important to understand the boundary of the product: the plugin controls which dates are available in a Gravity Forms date field. It does not replace a full resource management system, assign staff to time slots, track seat availability on its own, or serve as a full booking calendar for complex operational workflows without additional logic.

Who this plugin is a good fit for, and who should consider another option

The best use case for Gravity Forms Limit Dates is when a site already uses Gravity Forms and the date is just one field in the form. For example, a business might accept delivery requests, service inquiries, demo bookings, employee leave requests, consultation appointments, or document requests. In those cases, the admin usually does not want to build a separate booking module - they just want clear restrictions added to the existing form.

The plugin is especially useful for site owners, marketers, and web admins who do not want to maintain custom code using gform_datepicker_options_pre_init. The settings are available at the field level, so one form can be configured for weekdays, another for weekend events, and a third for a submission window. For developers, the value is different: basic rules stay in the interface, while edge cases can still be extended with official snippets and filters.

When it is a strong choice

Gravity Forms Limit Dates works well when the date selection rules can be expressed through a range, weekdays, exceptions, a relationship to another field, or a small supplemental snippet. Typical examples include delivery no earlier than the next business day, requests accepted only through a defined period, leave forms limited to the current year, a check-in/check-out range, or event registration with a few approved dates.

Another strong use case is when you want to keep Gravity Forms as the central point for collecting data. Notifications, confirmations, entries, conditional logic, integrations, and other fields stay in the familiar form, while the date restriction works as a clean extension specifically for the date field.

When another tool may be better

If you need hourly slots, automatic staff assignment, external calendar sync, booking payments, capacity management, and cancellations, date restrictions alone may not be enough. In that case, it makes more sense to look at a dedicated booking plugin or a Gravity Forms setup combined with additional tools that handle resources and scheduling.

The plugin can also be more than you need if the site only requires one simple block on past dates and you already have a developer maintaining a small JavaScript snippet plus server-side validation. But on most real-world sites, a supported admin-side configuration is easier for a team to manage than code nobody remembers a year later.

Practical rule of thumb: if the site manager needs to update blocked dates and weekdays without developer help, field-level settings are the better choice. If the rule depends on complex business logic, bookings stored in the database, and multiple resources, plan for an extension or a different class of solution from the start.

What to check before installation and first use

Preparation matters for a reason. Most calendar issues happen not because the plugin "doesn't work," but because the wrong date field type is selected, the theme breaks scripts, the page already has JavaScript errors, the site's time zone does not match the business schedule, or the form is embedded inside a nonstandard popup.

Before you configure anything, check four areas: basic Gravity Forms behavior, the field type, the page environment, and the business rules. This saves time because it helps you separate an interface issue from a restriction logic issue.

Platform and base form

First, make sure the form already opens, submits, and saves entries correctly without Gravity Forms Limit Dates. Add a regular Date field, set the input type to Date Picker, and confirm that the calendar appears in the form preview. Gravity Wiz documentation specifically notes that Limit Dates works with Date Picker. If the field uses manual entry or date dropdowns instead, you will not get the expected calendar behavior.

Do not start troubleshooting restrictions until the base date field works correctly on its own. If the calendar does not open in a clean test form, first check the theme, script optimization, popup widget conflicts, or browser console errors.

Time zone and business rules

For rules like "current date plus a few days," the WordPress time zone matters. The official Gravity Wiz documentation states that the current date for these restrictions is calculated using the WordPress setting, not the visitor's local time zone. That is the right behavior for a business operating in a specific city or region, but it can surprise an international audience.

Before launch, answer these questions:

• Which time zone should the site use to determine "today"?
• Should weekends be excluded from the minimum lead time, or are calendar days sufficient?
• Are there manually blocked dates that need to be treated as exceptions?
• Should the end date depend on the start date?
• Should users be allowed to type a date manually, or is it better to guide them through the calendar only?

The answers translate directly into field settings. Without them, admins often choose a range that feels "close enough" and then end up receiving requests for days the team does not actually work.

Installation and the first check in the form editor

Once the required perk is installed through Spellbook or the current Gravity Wiz delivery method, all work happens inside the form editor. Do not look for a large standalone settings page in WordPress: the core logic is configured on the specific Date field, because different forms - and even different fields in the same form - can have different rules.

Basic setup path

1. Open the target form in Gravity Forms.
2. Add a Date field from the advanced fields group, or select an existing date field.
3. Make sure Date Input Type is set to Date Picker.
4. Open the Perks tab in the field settings.
5. Set Minimum Date, Maximum Date, Days of the Week, and Exceptions based on your use case.
6. Save the form and test it both in preview mode and on the live page.

At this stage, do not try to configure every possible restriction at once. Start with one rule, verify it, and then add the next one. For example, first block past dates using Current Date, then add weekday restrictions, and then enter exceptions.

Quick check after enabling it

After the first save, open the form in a new window and verify three behaviors. The calendar should open, unavailable dates should either look different or be unselectable, and manually entering a blocked date should trigger a validation error on submission. That last point matters: the visual calendar helps the user, but the rule itself must still be enforced when the form is submitted.

Result check: if a blocked date cannot be selected with the mouse but can still be typed manually and submitted without an error, the setup is incomplete. Gravity Forms Limit Dates is expected to enforce restricted dates server-side.

Detailed date field configuration after installation

The most useful part of working with Gravity Forms Limit Dates is not "where to turn it on," but how to choose the right combination of settings. The date field has several independent layers: lower bound, upper bound, allowed weekdays, exceptions, inline calendar behavior, and submission validation. If you combine them without a plan, the calendar may look correct in one scenario and fail in another.

Minimum date: where the available period begins

Minimum Date controls the earliest date the user can select. The documentation describes three practical sources: a fixed date, the current date, and another date field. A fixed date works well for one-time events and closed campaigns. The current date is useful for requests like "not earlier than today" or "not earlier than a few days from now." Another date field is used when you need to link a start date and an end date.

For a typical delivery request, the most common setup uses Current Date with a modifier. For example, if the team needs lead time for processing, the minimum date may be "current date plus two business days." In the interface, that is configured by selecting the current date and using the Date Modifier to add days, weeks, months, years, or business days depending on your logic.

Do not confuse calendar days with business days. If you add two standard days on a Friday, the result may fall on a weekend. If the business rule specifically requires business days, use the appropriate modifier logic or a confirmed snippet for that edge case.

Maximum date: where the selection window ends

Maximum Date works in the opposite direction: it defines the latest valid date. This is useful for registration forms, seasonal services, current-period reports, or insurance and internal forms where future dates are not allowed. If the event date cannot be in the future, the maximum date can be tied to the current date. If booking is available only within a near-term window, the upper bound prevents users from selecting dates too far out.

Check the maximum date not only in the calendar but also through manual entry. A user may paste a date from the clipboard, browser autofill may suggest an old value, or a third-party script may alter the field. Server-side validation is needed specifically for cases like these.

Weekdays: the fastest way to remove extra options

The Days of the Week setting lets you keep only the required weekdays available. By default, all days are enabled. If you keep only Monday through Friday, the calendar starts behaving like a business-days-only form. If you enable Saturday and Sunday only, you get a form for weekend events.

This setting is especially useful for simple schedules. But if you have working Saturdays, holiday schedule shifts, or one-time closures, do not try to solve everything with weekdays alone. Start with the general pattern, then use exceptions for specific dates.

Exceptions: targeted closures and occasional allowed dates

Exceptions work like a toggle for a specific date. If the date is normally available, an exception makes it unavailable. If the date is normally blocked by the rules, an exception can re-enable it. For example, if the form is available on weekdays but one Saturday is a working day, you can add that Saturday as an exception.

The official documentation points out an important limitation: exceptions cannot fall outside the minimum and maximum date range. That makes sense. An exception refines availability inside the boundaries, but it does not extend the range itself. If you added an allowed date and it does not appear in the calendar, first check whether it falls before Minimum Date or after Maximum Date.

Inline calendar: when it is better than a popup

Enable Inline Date Picker displays the calendar directly in the form instead of only after clicking the field. This is useful when the date is the main action: booking an appointment, choosing a delivery date, or registering for an event. The user sees the available days immediately and does not need to open a popup calendar first.

The downside of inline mode is that it takes up more space. On a long form, that can hurt usability, especially if the calendar appears before more important fields. So enable it only when the date is truly the main choice, not a supporting field inside a large form.

What not to change without a reason

Do not change the date format, custom calendar scripts, JavaScript optimization, and Limit Dates restrictions all at once. If something breaks, it becomes difficult to identify the source. First configure the rules on a standard field, then add styles, popup behavior, caching, and any advanced scenarios.

If the site already has custom JavaScript for gform_datepicker_options_pre_init, check whether it duplicates the plugin's restrictions. Two different rule sources controlling the same field often lead to confusing behavior: a date looks blocked but still validates, or the reverse.

Linked date fields: start, end, and dependent ranges

One of the most valuable features in Gravity Forms Limit Dates is the ability to make one date field depend on another. This is useful for date ranges: rentals, time off, stays, temporary access, pickup and return, or event start and end dates. Instead of manually telling the user "choose an end date after the start date," you can connect the fields so the second calendar immediately responds to the first selection.

How the Start Date and End Date relationship works

In the end date field, you can choose another date field - the start field - as the Minimum Date. Once the first date is selected, the minimum date in the second field shifts accordingly. If needed, you can also add a modifier: for example, the end date must be at least one day after the start date. For the reverse limitation, you can use the maximum date of the first field if the form logic should prevent a start date later than an already selected end date.

This makes the form easier to understand. Users do not see impossible options and are less likely to run into an error after submission. At the same time, the admin does not need to write a separate validation rule for "end date earlier than start date" if the requirement can be expressed through Limit Dates settings.

Where linked fields require extra caution

Linked fields work well for simple ranges, but they become more complicated when blocked dates exist inside the range itself. For example, a user selects check-in and check-out dates, but one of the dates in between is unavailable. Gravity Wiz's official snippet library includes separate solutions for these cases, including blocking reserved ranges and preventing exceptions inside a linked period. That is no longer a basic two-click setup - it is an extension for a specific kind of business logic.

Before launching that kind of scenario, define the rule not as "like a hotel," but as a testable condition:

• Can users select a range if it contains a blocked day?
• Should only the start date be blocked, or the entire unavailable range?
• Should existing submitted entries automatically become exceptions?
• What should the user see if the requested range is unavailable?

If the answers depend on existing entries, inventory, or an external schedule, the basic settings may not be enough. In that case, use official snippets or a dedicated booking system.

Practical example: a delivery form limited to business days

Let us look at a concrete scenario. An online store or service company accepts requests through Gravity Forms. The customer must choose a delivery date. The team does not deliver on weekends, needs at least two business days to process an order, and has a few blocked dates due to inventory counts. The goal is for users to see only available dates immediately, while managers avoid receiving requests for impossible days.

Goal and preparation

The goal is for the "Preferred Delivery Date" field to allow only business days after the minimum processing lead time. The form should already include name, phone number or email, a delivery address, and a Date field with the Date Picker type. If the form sends notifications to a manager, first make sure those notifications work correctly without any date restrictions.

Configuration steps

1. Open the date field in the form editor and make sure Date Picker is selected.
2. On the Perks tab, set Minimum Date to Current Date.
3. Add a modifier for the processing lead time. If the rule must follow business-day logic, use business days rather than standard calendar days.
4. In Days of the Week, leave only the weekdays when delivery actually happens.
5. In Exceptions, add blocked dates: inventory counts, holidays, or days with no delivery staff available.
6. Save the form and open the public page as a regular visitor.

After saving, the calendar should immediately filter out impossible options. If inline mode is enabled, the user will see the available dates without clicking. If you use the standard popup calendar, test the field on the actual embedded page, not just in preview mode.

Verifying the result

Test the form as a user, not as an admin. Choose the nearest available date, submit a test request, and check both the Gravity Forms entry and the notification email. Then try entering a blocked date manually. The expected behavior is that the form should not accept a value that violates the rule.

If a blocked date still goes through, make sure the restriction is enabled on the correct field rather than a similar field in another form. Gravity Forms fields have their own IDs, and issues often come from copied forms or a new field being added instead of reusing the old one.

A nuance with late orders

Delivery workflows often have a cutoff time: an order placed after a certain hour should no longer qualify for the minimum lead time of "tomorrow." The basic Current Date setting does not always express that logic on its own. Gravity Wiz's snippet library includes an example that shifts the minimum date to the next day after a defined cutoff hour using the gpld_limit_dates_options_FORMID_FIELDID filter.

Below is an adapted educational example. Use it only after reviewing the official snippet and replacing the form and field IDs. Add code like this through Code Snippets, Code Chest, or a small site-specific plugin - not in WordPress core and not in the plugin files.

<?php
// Example: after 5:00 PM, the minimum delivery date shifts to tomorrow.
// Replace 123 with the form ID and 4 with the Date field ID.
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;
} );

After adding the snippet, test the form both before and after the cutoff time. If the result is unclear, temporarily disable the snippet and confirm that the base Limit Dates settings work again. That rollback is quick and safe because you are not modifying the plugin files.

Use cases: from customer requests to internal workflows

Date restrictions are useful for more than delivery forms. The more precisely you define the rule, the fewer manual follow-ups your team has to handle after form submission. Below are a few examples where Gravity Forms Limit Dates delivers practical value without turning the form into a separate booking system.

Consultation requests or on-site service visits

Consultations usually require lead time and blocked days when the team is not accepting requests. The minimum date protects the schedule from overly urgent requests, weekdays reflect the real operating calendar, and exceptions handle individual blocked dates. If consultations happen only on specific days, do not leave the entire calendar open to users - that creates a false sense of availability.

Event and registration forms

For an event with multiple possible dates, you can use a range and exceptions. For rare allowed dates, you can use the reverse approach through the official snippet that disables all dates and enables only those listed as exceptions. That is convenient when there are only a few valid dates and it is easier to list them than to block everything else.

Internal requests and HR workflows

Vacation forms, travel requests, equipment requests, and internal approval forms often need dates restricted to a specific period. In these cases, minimum date, maximum date, and clear result validation all matter. For an HR form, blocking past dates may be critical, while for an incident report the important rule may be blocking future dates instead.

Rental periods and temporary access

Linked date fields help when there is a start date and an end date. But if the date range needs to account for already occupied dates from previous requests, the base rule must be extended. In this kind of workflow, decide in advance what counts as unavailable: only the selected date, the full range, or a resource at a specific location. Without that decision, the form may look convenient while still creating scheduling conflicts for the manager.

How to test the result on the live site, not just in preview

The form preview is useful, but it does not replace testing on the real page. On a published page, the theme, optimization tools, cache, popups, page builder, and other scripts are all active. That is where calendar conflicts usually show up.

Testing mouse selection and manual input

Open the calendar and try selecting a date that should be unavailable. Then manually type that date into the field if the field accepts text input. For Limit Dates, it matters that the error appears when the form is submitted, because client-side validation can only guide the user - the final decision belongs to the server.

Also test an allowed date. If a valid day cannot be selected, the problem is often caused by overlapping rules: the upper limit is too close, an exception landed on the needed date, the weekday is disabled, or the linked field has not been selected yet.

Testing the time zone

If you are using Current Date, open the WordPress settings and make sure the time zone matches the business. Then test the form around the day boundary if that matters to your process. For international sites, decide upfront what matters more: the visitor's local date or the company's operating date. The plugin relies on the WordPress time zone for the current date, and that should be reflected in the wording around the form if necessary.

Testing after caching and optimization

If the site uses JavaScript bundling or deferred loading, temporarily test the form with optimization disabled or with the form page excluded from optimization. The date picker depends on proper script initialization. A single console error can break the restrictions even when the field settings themselves are correct.

Quick takeaway: a successful test is not just "the calendar looks good." You need to confirm three things: available dates can be selected, blocked dates cannot be submitted, and the notification plus the form entry receive the correct value.

Why the calendar may behave incorrectly and how to diagnose it

Problems with date restrictions often look the same: users see the wrong dates, the calendar does not open, or the form accepts a blocked value. But the underlying causes vary. Below is a practical troubleshooting path without endless trial and error.

The calendar does not appear for the date field

Symptom: the field looks like a regular text input, the calendar does not open, and the Limit Dates settings do not show up in the form behavior.

Possible cause: the field is not using Date Picker, the page has a JavaScript error, the form is embedded in a popup that initializes after page load, or script optimization broke the load order.

What to check: the input type in the field settings, the form preview, the browser console, and the same form on a normal page without a popup. If everything works in preview but not on the live page, the cause is almost certainly the page environment.

How to fix it: switch the field back to Date Picker, temporarily disable the conflicting optimization, exclude the form page from script bundling, and review the popup or builder settings. If the calendar comes back after optimization is disabled, re-enable performance tweaks one by one.

Users can select a blocked date

Symptom: a date that should be unavailable can still be selected in the calendar or submitted in the form.

Possible cause: the rule is configured on a different field, the weekday is still allowed, the exception is working in the opposite direction, the minimum or maximum date is not set, or the user is bypassing the calendar by typing manually.

What to check: the field ID, the Perks tab, the selected weekdays, the exceptions list, manual input behavior, and the server-side error after submission. If the date can be selected with the mouse, the issue is in the interface configuration. If it cannot be selected with the mouse but still submits manually, check server-side validation and third-party scripts.

How to fix it: simplify the rule to a single restriction, save the form, test it, and then reintroduce the remaining restrictions. That rollback approach helps isolate conflicts between the range, weekdays, and exceptions.

An allowed date became unavailable

Symptom: a valid business day cannot be selected even though it should be open.

Possible cause: the date falls outside Minimum Date or Maximum Date, the corresponding weekday is disabled, an exception was added, the linked field has not been selected yet, or a modifier shifted the range farther than expected.

What to check: first the range boundaries, then weekdays, then exceptions. If the date depends on another field, fill in the first field before testing the second one.

How to fix it: widen the range, remove the unnecessary exception, adjust the modifier, or add the specific date as an exception only if it still falls inside the overall range. Do not try to use an exception to open a date outside min/max - that limitation is officially documented.

The date shifts unexpectedly because of the time zone

Symptom: "today" or "tomorrow" in the calendar does not match what the team expects, especially in the evening or for visitors in other regions.

Possible cause: the current date is calculated using the WordPress time zone. That may differ from the visitor's time zone or from the company's actual operating schedule.

What to check: the Settings area in WordPress, the business rule for the date, and tests after midnight and around the cutoff time. If the site serves one region, the WordPress time zone should usually match that region.

How to fix it: align the site's time zone with the business rule, add clarification next to the field, and use a confirmed snippet for time-based cutoff logic. If the site is international, do not promise users a "local" date unless you have separate logic for that.

Linked fields behave unpredictably

Symptom: the end date does not update after selecting the start date, the range includes blocked dates, or the user can select an impossible period.

Possible cause: the second field is not linked to the first, the relationship is configured against the wrong boundary, exceptions inside the range are not being handled the way the business expects, or the calendar is not being reinitialized after the first field changes.

What to check: which field is set as the source for Minimum Date or Maximum Date, whether a modifier is required, whether there are exceptions inside the range, and whether an official snippet is needed to prevent those periods.

How to fix it: first make the simple rule work: "end date cannot be earlier than start date." Then handle unavailable ranges and exceptions separately. If the logic needs to account for previous entries, use official Gravity Wiz snippets or a dedicated booking system, not a random code fragment from a forum thread.

Safe enhancements and when not to write code

Gravity Forms Limit Dates has an official snippet library, and that is a major advantage for more advanced scenarios. But snippets should be used as targeted extensions, not as a substitute for a well-planned configuration. If the rule can be expressed through Minimum Date, Maximum Date, weekdays, and exceptions, start with the interface.

When a snippet makes sense

A snippet is justified when the rule depends on previously submitted entries, time of day, a selected value in another field, or logic that has no dedicated option in the interface. Examples from the official library include setting the next available date as the default value, automatically blocking already selected dates when uniqueness is enabled, applying different conditions for different locations, or allowing only the first or last days of the month.

Before installing code like that, check the source, the page update date, any comments from the developer, and the recommended installation method. For non-developers, a snippet manager is usually the safest choice because the code can be disabled quickly. For agencies, it is safer to keep these rules in a separate site-specific plugin so they do not disappear during a theme change.

When code is better left out

Do not add code if you cannot clearly explain what rule it changes. Do not use snippets that require editing Gravity Forms, Gravity Wiz, or theme files. Do not copy old solutions written for the generic jQuery UI Datepicker if they ignore Gravity Forms server-side validation. And do not install two different scripts that both try to control the same date field.

If you only need to change the appearance of the field, use Gravity Forms CSS selectors for the Date field and style it through the theme. If you need to block dates, use Limit Dates. If you need a resource calendar, do not try to fake it with a long chain of snippets - choose a tool designed for resource-based scheduling.

When Gravity Forms Limit Dates is the right choice

Gravity Forms Limit Dates is worth using when your requirement sounds like this: "let the user select only the correct date in a Gravity Forms form." The plugin covers a practical set of rules: min/max, current date, modifiers, weekdays, exceptions, linked fields, inline calendar, and both client-side and server-side validation. The main thing is not to turn it into a resource booking system once the business logic goes beyond what a date field can reasonably handle.

Before launch, build a simple test scenario: one valid date, one blocked date, one out-of-range date, manual input, and form submission. If all five checks pass, the manager receives the correct entry, and the user sees a clear calendar, the setup is working properly.

If, after reading this, you can see that the product fits your form, move on to testing it on a staging copy of the site or in a separate form. Closer to the final rollout, you can download the ZIP archive, install it in the working environment using the standard WordPress process, and repeat the checks on the actual page.

The most reliable result comes not from piling on as many restrictions as possible, but from having one clear rule. Define which date the business actually needs, configure that rule in the field, verify the calendar and server-side validation, and document rare exceptions separately for the team.