This release lets AI assistants manage calendars, updates a calendar as soon as its form is submitted on the same page, and improves conditional logic. It also strengthens security and fixes many issues with event links, dragging events, and the Calendar widget.
Note: Clear your site's page cache after updating so secured calendars show events from other calendar feeds.
🚀 Added
- 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.
✨ Improved
- 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).
- Enhanced conditional logic:
- 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".
🔒 Security
- Changes to calendars with "Enable security for this calendar" turned on:
- 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.
- Improved the security of showing events from another calendar feed:
- 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.
- Improved the security of event links and of HTML in events:
- 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.
🐛 Fixed
- 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.
- 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.
- 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;
- On calendars that date events by when entries were created or last updated, dragging an event appeared to move it without saving anything, instead of returning it to its original date (those dates can't be changed).
- On sites that display PHP warnings, calendars showed no events from feeds on other websites added with "Display Events from Another Calendar Feed".
- 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.
💻 Developer Updates
- 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.
- 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.
🔧 Updated