GravityCalendar

Original file

Version

2.26.0 Changelog

Updated

1 Nov 2026

Auto-update

Yes How it works

File scan

Clean Details

Members can request updates and report problems from here.

About this template kit

GravityCalendar is a handy WordPress plugin that connects Gravity Forms with The Events Calendar, turning your form submissions directly into calendar events.

It’s perfect for event managers, booking sites, and community platforms that want to automate their scheduling workflow without any manual fuss. Users can map Gravity Forms fields to event details like dates, titles, and locations, saving heaps of time. If you’re running a busy events-based site and already rely on these two popular tools, GravityCalendar is a brilliant addition to your setup.

Changelog

Version 2.26.0

Latest 22 Oct 2026

7 new5 improved1 security37 changed

New

Calendars added to a View's Single Entry layout with the [gravitycalendar] shortcode did not appear when the entry was opened in a lightbox, and the [gravitycalendar_copy_button] button there did not copy the calendar's link.
On sites that display PHP warnings, calendars showed no events from feeds on other websites added with "Display Events from Another Calendar Feed".
Added eight abilities to the WordPress Abilities API under gk-gravitycalendar/ (calendars-list, calendar-get, calendar-settings-schema, events-list, calendar-create, calendar-update, calendar-delete, and event-reschedule), which GravityKit Foundation exposes as gc_* MCP tools.
Added gk/gravitycalendar/secret/allow-legacy filter to control whether calendars accept their secret from before this update (by default, only calendars secured before the update accept it, in the places listed above; return true to accept it everywhere or false to require the new secret everywhere).
Added gk/gravitycalendar/events/form-submit/reload filter to turn off reloading a calendar's events after its form is submitted on the same page.
Added gvFullCalendar.reloadEntryEvents( calendar_id ), which reloads a calendar's entry events without changing its date, and the gk/gravitycalendar/events/reloaded event, which fires on the calendar element and bubbles up to document when a reload finishes.
Secrets are now stored in the gk_gravitycalendar_secret_key option, alongside gk_gravitycalendar_secret_legacy_feeds (calendars that still accept their old secret) and gk_gravitycalendar_secret_legacy_since (when that list was created); copy all three when migrating a site, or shortcodes added after this update show nothing on the new site.

Changed

Note: Clear your site's page cache after updating so secured calendars show events from other calendar feeds.
AI assistants connected through the GravityKit MCP can now list, create, change, and delete calendars, list a calendar's events, and move or resize events, limited to what the account they sign in with is allowed to do on the calendar settings screen or with drag-and-drop editing.
Calendars on the same page as their form now show a new entry as soon as the form is submitted with AJAX, without reloading the page or leaving the month being viewed (entries the calendar would not otherwise show, such as those awaiting approval, stay hidden).
Condition dropdowns that search users, entries, or posts now load their choices as soon as they are opened
Conditions using the {get} merge tag found no entries or the wrong ones when the value in the page address contained &, +, or % (such as "Research & Development"), and changed other {get} merge tags on the page
Conditions on GP Nested Forms fields and other fields that store several users, posts, or entries (such as Dynamic Lookup and Populate Anything fields) were slow on forms with a few hundred entries
"Has any of", "has all of", and "has none of" conditions on Multi Select fields checked only the first selected value
Condition dropdowns could open behind the WordPress admin bar, pressing Enter on a selected choice cleared it, and pressing Enter on the clear button did nothing
When WordPress was set to a language other than English, date conditions showed month names, weekdays, and labels in English, and labels with an apostrophe showed ' (such as "n'est pas" in French)
Once a date was picked, the weekday names in a date condition's calendar were off by one day in time zones west of UTC (such as the US), and screen readers announced that calendar as "Event".
Each site now uses its own unique secret, and existing shortcodes and blocks keep working with the old one
Posts created or changed after this update by users who cannot edit calendars need the new secret, so insert the calendar again or have a user who can edit calendars re-save the post
ACF fields on options pages, users, and terms accept only the new secret
The Calendar block shows a secured calendar's secret and preview only to users who can edit calendars
The Elementor widget shows a secured calendar only on pages last saved by a user who can edit calendars or, for calendars secured before this update, on pages unchanged since.
Feed events of secured or turned-off calendars are now available only on pages that show the calendar
Feed addresses on a local or private network are refused when saving the calendar's settings, and are not fetched
Previously saved feeds that are now refused, such as those on port 8443 or with a username and password in the address, are listed in a notice on the calendar's settings screen and recorded in the log.
Event links now open only web addresses, or email, phone, and text message links whose mailto:, tel:, or sms: is typed into the Event URL setting (such as mailto:{Email:3})
With "Allow HTML Content" on, event titles, descriptions, and locations keep links and formatting such as bold text, but drop anything that could run a script and embedded content such as iframes
Turning on "Allow HTML Content" now requires a user who can post unfiltered HTML, such as an administrator on a single site.
Calendars whose events link to a Single Entry page caused a fatal error when that View had been permanently deleted.
The Calendar widget showed an empty calendar on Views that join forms with Multiple Forms when "Display events for" was set to "Entries shown on the page", or to "All View entries" without Dynamically Load Events, and always when the calendar belonged to the joined form.
With Dynamically Load Events turned on, the Calendar widget showed no events after a search that sent more than one value for a field, such as two ticked checkboxes or a date range.
Issues with event links:
On sites with permalinks set to "Plain", event links to an entry on another page opened the calendar's own page or a "Page not found" page
Event links built with merge tags lost every query parameter after the first
Custom event links entered without http://, such as example.org/page, opened a missing page on your own site (links without http:// or a leading / are now treated as web addresses, so start links to your own site with /, such as /page/{entry_id}).
Issues with dragging events:
Times were saved in the wrong format for the form's Time field, such as 2:00 pm instead of 14:00 in a 24-hour field
The Calendar block listed calendars from forms in the trash.
Accessibility issues:
Accessibility checkers such as axe reported an error on events with a tooltip in the month, week, and day views
Screen readers announced the calendar's previous and next arrows as unnamed images.
When WordPress was set to a language other than English, the "Click to copy" and "Copied!" text beside a calendar's shortcode and the "Invalid URL" error for the Calendar Feed URL setting were always in English.
To show a calendar feed from a server on a private network, allow its host with WordPress's http_request_host_is_external filter, and a port other than 80, 443, or 8080 with http_allowed_safe_ports.
Foundation to version 1.38.0.