| 开发者 | Paxrank |
|---|---|
| 更新时间 | 2026年8月30日 05:51 |
| PHP版本: | 8.0 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
do_action( 'paxrank_gf_date_blocker_init' );
apply_filters( 'paxrank_gf_date_blocker_should_load', bool $should_load );
/wp-content/plugins/, or install it through the Plugins screen in WordPress.Yes, the date picker, the plain text input, and date fields that use day/month/year dropdowns. Server-side validation reads each field's own configured date format, so mixed formats across your forms are handled correctly.
Yes. Leave the end date empty to block a single day, or fill it in to block the whole range from start to end in a single record.
They are always blocked. The plugin is built for future bookings, and past dates cannot be added from the admin interface either.
The one your forms actually display, since the setting controls how dates are shown and entered in the admin. Server-side validation is independent of it and uses each field's own format, so a field with a different format still validates correctly.
The plugin detects it, shows an admin notice, and stays inert. It does not throw errors, and your restrictions are preserved for when Gravity Forms comes back.
Only if you ask it to. Data deletion is opt-in, under Uninstall Options. If you leave that box unchecked, your restrictions and settings survive uninstalling.
Only the visual layer. The restrictions the date picker greys out are printed into the page, so a cached page keeps showing the restrictions that existed when it was cached — until the cache is purged, a newly added restriction may not be greyed out yet (or a removed one may still look blocked). Enforcement is unaffected: form submissions are POST requests, which bypass the page cache, and the server validates every submission against the live restrictions. If you change restrictions often, purge your page cache after saving, or exclude your booking pages from caching.