Replace ICS file with calendar links and clean up

[keunes]

Update the event system to replace the ICS file with direct links to add events to calendars.

[keunes]

To check: possibly update 'Community meeting' to 'Community call'; use page slug as default for recurring meeting calendar URLs; make feature request against Davis.

[keunes]

@ByteHamster on this point:

use page slug as default for recurring meeting calendar URLs

What do you think? It is definitely feasible. We can also get rid of the 'meeting room' front matter using similar logic. Both (calendar-path and meeting-room) can be set automatically based on the slug (file name) if the meeting/event is online and a) recurring or b) one-off and upcoming.

The downside is that it's less explicit:

• In (the unlikely) case we have another recurring event, we need to remember to set up the redirect in the htaccess file with the same slug as the event file on the website.
• For all new (one-off and recurring) events we need to remember to align the meeting room URL that we add in the calendar with the slug as the event file on the website.

I think that this is fine, though. In any case I would make these front matter fields optional, so we can still explicitly set them to something different if we want.

[ByteHamster]

If it is unlikely that we add another recurring event, does it matter to have it filled in automatically? Making it explicit means that we need to remember less. An AI won't remember this either. If it's explicit in the code, there is less risk for things going wrong

[keunes]

Ok, thanks, makes sense - let's leave it explicit. Then the PR is ready to review.
Feature request against Davis to have event-specific subscription URLs: tchapi/davis#260

[Copilot]

Pull request overview

This PR updates the website’s events “add to calendar” flow by removing the generated /events.ics feed and replacing it with calendar subscription / direct .ics links via a new “Add to calendar” modal and updated event metadata.

Changes:

• Replace the old ICS modal + /events.ics generation with a new “Add to calendar” modal and calendar link metadata (calendar-path, uid).
• Update event link rendering/styling and the copy-to-clipboard helper to use an explicit event parameter and data-copy-url.
• Add a Jekyll plugin to enforce stable permalinks for recurring events and introduce calendar_base_url configuration.

Reviewed changes

Copilot reviewed 25 out of 25 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
events/index.html	Switches to the new add-to-calendar modal include on the events overview page.
events.ics	Removes the generated global ICS feed.
events-with-RDATE.ics	Removes the alternative ICS feed variant.
assets/js/copy-url.js	Updates clipboard copy helper to use event + data-copy-url.
_sass/_custom.scss	Adds grid border styling for the event links block.
_plugins/recurring_events_permalink.rb	Ensures recurring events get a non-date-based permalink when none is set.
_layouts/event.html	Reworks event link visibility logic, adds calendar URL variables, switches to new modal include.
_includes/share.html	Updates share “copy link” button to pass the click event and use data-copy-url.
_includes/ICS-modal.html	Removes the old ICS modal implementation.
_includes/event-link-visible.html	Introduces shared logic for whether each event link should be shown.
_includes/add-to-calendar-modal.html	Adds the new add-to-calendar modal UI and buttons.
_i18n/en/general/events-add-calendar-modal.md	Updates the modal body copy.
_i18n/en/general/event-sidebar.md	Updates sidebar CTA to use the new calendar subscription URL + copy behavior.
_i18n/en/events/community-meeting.md	Removes old community meeting copy file.
_i18n/en/events/community-call.md	Adds new community call copy file.
_i18n/en.yml	Updates/extends event calendar-related strings.
_events/needs-decision.md	Updates event metadata for new calendar/link approach.
_events/community-meeting.md	Removes the old recurring event definition.
_events/community-call.md	Adds the renamed recurring event definition using new metadata.
_events/2026-01-31-fosdem.md	Updates UID and location formatting for the new link scheme.
_events/2022-07-22-10 year anniversary.md	Updates meeting-room format and reorders UID.
_events/0_A meeting template.md	Updates the event template to reflect the new calendar/link fields and requirements.
_data/ics-timezones.yml	Removes ICS timezone data (no longer needed after ICS feed removal).
_data/event-links.yml	Replaces the ICS link entry with a calendar-path link and updates base URLs.
_config.yml	Adds calendar_base_url configuration.

Comments suppressed due to low confidence (1)

_includes/add-to-calendar-modal.html:23

• The "Download ICS" link is always rendered, but event_ics_url is only assigned when page.uid is present. On pages that include this modal without setting event_ics_url (e.g., the events index), this will produce an empty href. Wrap this link in a conditional (or provide a safe fallback URL) so the button is only shown when the URL is available.

        {% endcomment %}
        <a role="button" class="btn btn-primary" href="{{ event_ics_url }}">{% t events.general.download-ics %}</a>
      </div>

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[ByteHamster]

Can't we just use the same calendar link property for both instead of trying to be smart? That's a lot more explicit

[keunes]

The logic is:

• recurring events: we want to encourage people to subscribe to the remote calendar and receive updates (whether they subscribe to all events or just this one)
• one-off events: if they don't want to subscribe to all our events, we should offer a quick way to add just this one (e.g. FOSDEM) to their calendar.

For this distinction, we need different info. We create human-readable slugs via htaccess in Davis for recurring events, which we shouldn't be bothered to do for one-off events.

Side note: UID is actually required always - our PR workflow fails without it.

• For now: Also for recurring events we offer the same options as for one-off events, until CalDAV subscription URLs for individual (recurring) events in a calendar tchapi/davis#260 might get addressed
• Long-term: While not strictly necessary for recurring event links, I think it's still good to mandate it just in case. I'll update the description in the event template file.

[ByteHamster]

I think the GUID was only needed when we generated events manually. Now, with the dedicated calendar tool, I think we can remove the CI check and the GUID from the files. Then we can still give the path to whatever Davis ends up giving as link.

[keunes]

Ok, we can drop the GUID being mandatory for events. Events then should have either a calendar-path or a guid (as written in the template).
Because it's currently not possible to subscribe to a specific event via CalDAV (see link to Davis), we have two options for recurring events:

1. provide only an all-events CalDAV link
   • downside: folks are maybe less likely to subscribe as they're only interested in the community call and don't want to have all the Needs: Decision calls.
2. provide an all-events CalDAV link + guid-based iCal link to the event series
   • downside: the iCal link doesn't provide calendar name or colour and (at least on Android) you need a special app (e.g. ICSx⁵) to subscribe.

difference between CalDAV and iCal according to Claude

Both rely on polling — neither method has true server push in practice.

With iCal, the client downloads the full .ics file on whatever interval it's configured for (often every hour or even less frequently, since it's a crude fetch).

With CalDAV, it's also polling, but typically at a shorter interval (Thunderbird defaults to every 30 minutes, though configurable). The advantage is that CalDAV only fetches what's changed since the last sync rather than re-downloading everything, so shorter poll intervals are cheaper and more practical.

There is a CalDAV extension called calendar-auto-schedule and a push notification mechanism, but real server-push for CalDAV is rare in self-hosted setups and Sabre/Davis doesn't implement it as far as I know. So in your case, both methods would effectively behave the same way in terms of update latency — it's just a matter of how aggressively the client polls.

Do you have a preference between the two?

[ByteHamster]

2 sounds nice to me. I mean, for CalDav you also need an app right?