The v1.4 line is the biggest single release jump in the plugin’s history so far. The Bookings tab gets a real calendar view, the public booking widget gets multi-slot range selection, form fields gain per-resource scoping, the email-delivery stack gets dramatically simpler, and a long-overdue hardening pass adds GDPR/FERPA hooks, OTP rate-limiting, and an anti-bot honeypot. v1.4.0 was the headline release; the patch line ran through v1.4.20 over the following weeks. Twenty patches sounds like a lot — most are polish and bug fixes against the new feature surface, which is the right kind of busy.

If you’re updating from v1.3, the migrations are automatic and additive. Multi-slot defaults off; per-service form fields default to “shared across resources” (existing behavior); the email-delivery change is a no-config improvement for sites already using a SMTP plugin.

What’s new in v1.4

Bookings calendar view with filter bar + detail drawer

The Bookings tab previously rendered as a long scrolling list, which got unreadable past a few weeks of activity. v1.4.0 ships a proper calendar:

Week and Month views — toggle between them; each booking shows as a chip on its day.
Filter bar along the top — status pills (Pending / Approved / Rejected / All), page and resource dropdowns to scope the view.
Side drawer opens on click — full booking record (booker, slot, resource, custom-field responses, approval history) plus approve/reject actions inline. No more “click booking → navigate to detail page → click back.”

Most facility managers using the plugin reported the same thing: the moment they had more than 20-30 active bookings, the old list view became the bottleneck for daily operations. The calendar fixes that for the same workflow.

Multi-slot range bookings

Until v1.4, every booking was exactly one slot. A three-hour vehicle reservation was three separate bookings. v1.4.7 adds multi-slot range selection to the public booking widget:

Admin toggle per page: allowMultiSlot boolean in calendarSettings.
Per-page cap: maxSlotsPerBooking integer, default 4, clamped between 1 and 24.
Range-click UI on the public widget: first click selects the start slot, second click on a later slot in the same day selects the range; click anywhere to reset.
Slot picker state refactored from selectedSlot to selectedSlots array — internal change, externally invisible.

The Builder Step 2 only shows the multi-slot toggle when slot duration is set to “Custom” — for preset durations (30 min / 1 hour / etc.) the range-select doesn’t apply the way it does for variable-length blocks.

Future versions may add multi-day and non-consecutive slot selection (the UI stubs are visible in Builder Step 2 with “Coming soon” tooltips). The schema and reservation-logic work for those is real and not on the near-term roadmap; v1.4.7’s range-select handles the most common case.

Per-service form fields

v1.4.3 introduces per-resource form-field scoping. A new resource_label column on the form-fields table determines which resources a given field applies to:

Shared across all resources (the default — preserves existing v1.3 behavior).
Scoped to a specific resource — the field only appears in the form when that resource is selected.

So Vehicle 1’s booking form can ask for a License plate and Driver name, while the conference-room form on the same page asks for Expected attendees. Both forms live on the same booking page; the booker sees only the fields relevant to their selection.

The migration to add the column runs automatically on upgrade (DB_VERSION 1.3.2 → 1.4.3). Existing fields stay shared (preserving v1.3 behavior); flip the scope on individual fields as needed.

Markdown links in form labels and page descriptions

v1.4.2 adds Markdown-style link syntax across the admin text inputs:

[Cancellation policy](https://example.com/policy)

Works in field labels, page descriptions, checkbox text, anywhere you’d previously have had to choose between plain text and embedded HTML. The public widget renders these as <a target="_blank" rel="noopener"> links. Saves a configuration field (no separate “link URL” column needed) and lets you sprinkle in references to policies, terms, instructions without leaving the editor.

Theme picker for the public booking form

v1.4.20 adds six preset color palettes for the booker-facing form — Forest, Ocean, Sunset, Lavender, Rose, Slate — plus custom hex if you want to match your site exactly. Applies only to the public widget; the admin chrome stays neutral so it doesn’t compete with WordPress’s own theme.

What got better

Dropped Resend HTTP API; `wp_mail()` is now the only path

The biggest under-the-hood simplification in v1.4. Previously, booknslot supported either Resend’s HTTP API directly (requiring an API key in plugin settings) or WordPress’s native wp_mail(). The dual-path code was a maintenance burden and a source of subtle bugs (different rate limits, different error handling, different sender-name behavior).

As of v1.4.4, wp_mail() is the only delivery path. Configure SMTP via any of the existing WordPress mail plugins (WP Mail SMTP, FluentSMTP, Post SMTP, etc.) and booknslot uses whatever transport you’ve set up. Test deliverability with the new POST /booknslot/v1/settings/test-email endpoint surfaced as a “Send test email” button in Settings → Email delivery.

Side-benefit: removes one third-party dependency from the plugin’s supply chain. The sender-address wp_mail_from and wp_mail_from_name filters are now respected, so customizing the from name and address works the same way it does for every other WordPress email.

ITS-readiness hardening

v1.4.6 ships a coordinated set of changes aimed at making the plugin clearable through enterprise IT-security reviews:

GDPR / FERPA export and erase hooks. Implements the wp_privacy_personal_data_exporters and wp_privacy_personal_data_erasers WordPress filters so the Tools → Export Personal Data and Tools → Erase Personal Data screens can scrub or export booker data on request. The audit history (state changes, timestamps) stays; the personally-identifying fields get anonymized or removed.
OTP rate-limiting. 10 requests per 15 minutes per IP; 5 requests per 60 minutes per email address. Stored in WordPress transients. Prevents OTP-bombing abuse without rate-limiting infrastructure outside WordPress.
Honeypot field. An off-screen companyWebsite input that legitimate users never fill in. Bot submissions get rejected silently before consuming an OTP send.
Security contact registration. Plugin metadata now includes a security disclosure email so security researchers know where to report.

Drawer + admin UI polish

Most of the v1.4.5 through v1.4.20 patch cycle is fast-iteration polish on the new admin surfaces:

Drawer no longer hides behind the WordPress admin bar.
Form-field overflow fixed when long descriptions hit narrow drawer widths.
Slug auto-generation from name fields (typeable but auto-populated).
Info-icon tooltips across the admin (toggle descriptions, section subtexts, multi-day/non-consecutive “Coming soon” stubs).
Confetti on first publish (then reverted — too much).
Lead-time interpretation fixed for sites where server and browser timezones differ; auto-pick of first day with a defensive resource fallback.

Twenty patches in a release line is honest about what shipped: a lot of new surface that needed real-world stress-testing to settle.

What’s coming next

The v1.5 line is queued up and the email-template editor is the headline:

Real email-template editor. Today, customizing the OTP / confirmation / approval emails means edits scattered across several inputs. v1.5 replaces that with a dedicated editor that has 25 ready-made HTML presets (Stripe-style tables, soft cards, friendly OTP blocks, formal welcome designs) plus a live preview alongside editable HTML in the same pane.
Email branding. A consistent envelope (logo, header color, footer HTML, signature) wraps every transactional email — set once in Settings, applies everywhere.
CTA button helper. A small visual builder for the call-to-action button in emails — outputs email-safe inline-styled HTML so the button looks right in Gmail, Outlook, and the mobile clients.
{all_form_fields} placeholder. Dump every custom form field a booker filled in into a template with one variable; no more updating the email template every time you add a new field.

The roadmap beyond v1.5 — self-hosted plugin updater, auto-snapshot before update, manual export/import — is on the project’s longer view.

Where to go from here

Update from Plugins → Installed Plugins. The form-fields migration runs automatically on first admin load. Multi-slot defaults off (existing pages keep single-slot behavior); the theme picker defaults to “default” (matching the v1.3 styling); the email-delivery change is no-config — if you already have SMTP configured via a plugin, it Just Works.

If you’re evaluating, the live demo runs the current release on mock data with OTP code 123456. About 90 seconds end-to-end.

If you missed earlier releases, the v1.3 update post covers the per-resource approval workflows and the public-widget validation pass that landed before v1.4.