i have successfully rebuild my Discourse instance🥲
Discourse’s official discourse-calendar plugin already supports .ics export, which is extremely useful for sharing Discourse events externally. However, many communities — particularly in education, government, or enterprise — rely on external iCal feeds to publish event information (e.g. from Moodle, Office365, Google Calendar, or institutional CMS platforms).
At present, there is no built-in way to import or sync from .ics sources. This limits Discourse’s use as a true calendar hub for communities that already publish important schedules elsewhere.
Feature Proposal
Add iCal feed sync (import from .ics URLs) to the Discourse Calendar plugin.
Core Features
Configure an .ics feed URL for a calendar-enabled category or topic.
Automatically import events into the calendar, matching the .ics feed.
Specify a sync interval (e.g. hourly, daily) or allow a manual “Sync now” button.
Use the event UID field to prevent duplicates and update modified events cleanly.
Optional Configs
Tag or label imported events to show their external source.
Choose between:
One-way sync (external → Discourse only),
or two-way sync (editing synced events inside Discourse pushes changes back — future scope).
Support multiple .ics feeds per calendar, merged into one view.
Visual indication that an event is externally synced (e.g. “Synced from: outlook.university.edu”).
Use Cases
Sector
Example Use Case
Education
Auto-populate student forums with term dates, course schedules, exams, etc.
Government
Sync official events from CMS or intranet to a public-facing community calendar
Companies
Mirror internal meeting calendars (from Outlook or Google Calendar)
Events forums
Integrate speaker lists or session schedules from external providers
Security and Privacy
Calendar feeds could support public or tokenized access (e.g. URL containing secret token).
Support for OAuth2 / Basic Auth could be a future enhancement.
Similar need discussed in older threads, e.g. here
Compatibility
This feature would not require discourse-events (now deprecated), and would work natively with the existing Discourse Calendar syntax ([calendar] and [event]). Users would still be able to create native Discourse events manually — iCal sync would just augment these calendars.
Would love to hear if this feature is already on the roadmap — or if others in the community would find it valuable.
@Ethsim2 This would be a huge feature, and I’ve been digging into how feasible it is now that Discourse is switching to FullCalendar.
@sam linked directly to fullcalendar.io recently, and it turns out FullCalendar now has first-class support for .ics feeds via their official plugin system — so the heavy lifting is already done by the library.
Proposal: Enable .ics Feed Sync Using FullCalendar’s Native Support
With the upcoming FullCalendar v6 integration into Discourse, the groundwork is in place to support this feature natively.
FullCalendar’s @fullcalendar/icalendar plugin (with ical.js under the hood) allows you to load public .ics feeds like so:
That’s all it takes to render a remote iCal feed into the calendar UI — no custom parsing, just plug-and-play.
Suggested Implementation Steps for Discourse
Add @fullcalendar/icalendar and ical.js to the plugin (once FullCalendar v6 is fully landed).
Add an admin/plugin setting (or per-category option) for inputting one or more .ics URLs.
On the client side, render the feed into the calendar view.
(Optional) Implement server-side syncing that:
Periodically fetches the feed
Parses new/updated events
Creates or updates associated Discourse topics
Sync Frequency
It’s important to note that FullCalendar’s default .ics handling only fetches the feed on initial calendar load in the browser. That means:
There’s no daily or automatic refresh.
Users will see a stale copy unless they reload or manually trigger a refresh.
There is no persistence — if a user navigates away, the feed data is gone.
To make this truly useful, Discourse would ideally:
Run a daily (or scheduled) Sidekiq job that fetches the feed server-side.
Cache the parsed events for consistent rendering across users.
Optionally link events to topics or create new ones for full integration.
This would allow proper sync behavior and revive a key feature previously handled by Angus’s plugin — but using a clean and maintainable foundation.
Benefits
Seamlessly integrates .ics feeds from Google Calendar, Outlook, iCal, etc.
Makes Discourse a calendar consumer, not just an exporter.
Great for community forums, student groups, civic events, etc.
Built entirely on supported FullCalendar features — minimal custom JS needed.
Would love to see this land now that the calendar plugin is getting attention again. Happy to help test it or contribute to a proof-of-concept.
Sorry @Halden42 but I’m a bit confused about your post.
I understand that Discourse is “fixing the foundations” of the calendar system with the FullCalendar upgrade, but I’m worried about how much time it would take me to manually populate a busy calendar. I use the Discourse GUI every day for everything, and having to duplicate content outside the interface is a non-starter.
I noticed you mentioned a feature I really miss from Angus’s plugin, which I think captures the main point of syncing events into Discourse:
This part would be essential for my use case.
But I’m concerned because you didn’t go into any detail about how that could be implemented. Could you explain what that would look like in practice? Would Discourse create one topic per event? Would it support updates or deletions if the source calendar changes?
That’s the part I’d need to rely on most, and I’m just not sure yet how close we are to it.
Bedankt @Ethsim2 — dat is een geweldige vervolgvraag, en ik denk dat uw bezorgdheid precies de juiste is: het gaat niet alleen om het weergeven van gebeurtenissen uit een .ics-feed, maar om het integreren ervan in Discourse op een nuttige, traceerbare manier.
Toen ik zei “gebeurtenissen koppelen aan onderwerpen of nieuwe maken”, stelde ik me een opstelling voor die vergelijkbaar is met hoe Angus’ plugin vroeger werkte — waarbij elke gebeurtenis in de feed overeenkwam met een onderwerp op Discourse, en updates van de feed in de loop van de tijd in het onderwerp werden weergegeven.
Op dit moment slaat FullCalendar op zichzelf geen gebeurtenissen op — het rendert ze alleen vanuit de feed bij het laden van de pagina. Dus als een gebeurtenis uit de feed verdwijnt (d.w.z. extern is geannuleerd of verwijderd), verdwijnt deze gewoon geruisloos uit de kalender-interface.
Maar dat is niet goed genoeg voor de meeste forumgebaseerde workflows, vooral waar gebeurtenisberichten worden gebruikt voor discussie, RSVP’s of aankondigingen.
Hier is wat ik hiervoor zou willen voorstellen:
In plaats van het onderwerp te verwijderen wanneer een gebeurtenis uit de feed verdwijnt, zou Discourse het volgende kunnen doen:
Het onderwerp behouden
Een regel bovenaan toevoegen zoals: ⚠️ Deze gebeurtenis is geannuleerd of verwijderd uit de bronkalender.
Optioneel het onderwerp vergrendelen of de-publiceren, afhankelijk van de voorkeur van de beheerder
Dit zou de context behouden, reacties mogelijk maken en de annulering zichtbaar maken — zonder iets te verwijderen. Technisch gezien is dit goed te doen: we zouden gewoon markeren dat de UID niet langer bestaat in het .ics-bestand en de status van het bijbehorende onderwerp bijwerken.
Dus ja — hoewel FullCalendar zelf die status niet beheert, zou Discourse dit kunnen afhandelen op de synchronisatielaag. De taak die de feed ophaalt (bijv. via Sidekiq) zou bijhouden welke gebeurtenissen vroeger bestonden en nu niet meer, en het bijbehorende onderwerp dienovereenkomstig markeren.
Als er genoeg mensen geĂŻnteresseerd zijn in dit, denk ik dat we een behoorlijke specificatie zouden kunnen uitwerken. Het zou niet moeilijk zijn om een prototype te maken.
Thanks for the thoughtful reply @Halden42 — this clears up a lot.
What you described here…
…is exactly the core use case I’ve been trying to recover since moving off Angus’s plugin. For me, the most critical part is not just rendering events visually, but syncing a live external calendar into the forum, where each event has a topic, and changes to that event (e.g. cancellation, reschedule) are reflected in that topic over time.
I’d be happy with a one-way sync model to start—read-only from .ics to Discourse—and even just basic update detection would cover 90% of my use cases. A “cancelled” status showing in the event topic if it’s removed from the feed would be ideal too, rather than deleting the topic outright.
If there’s a preferred place to propose a spec for this—perhaps once the FullCalendar upgrade stabilises—I’d be very interested in contributing or testing.
We houden meerdere Office 365-agenda’s bij — elk met zijn eigen .ics-feed — voor verschillende soorten vergaderingen: Executive Committee, Public Engagement Sessions, Internal Working Groups, enzovoort. Deze feeds zijn al goed gestructureerd en worden regelmatig onderhouden door griffiers en administrateurs.
Ik ben een farmaciastudent in de VS en onze universiteit biedt al onze stageplanningen, examens en praktijklessen via een kalenderportaal. De feed-URL’s eindigen niet op .ics, maar wanneer ik ze in Chrome open, downloaden ze onmiddellijk een geldig .ics-bestand. Ze zijn dus zeker standaard iCal-feeds - alleen met een andere URL-structuur.
Tot voor kort gebruikte ik Angus’ plugin, en die verwerkte deze feeds perfect. Elk evenement genereerde een onderwerp, en ik kon verschillende feeds naar verschillende categorieën routeren (bijv. “Therapeutics”, “Rotations”, “Exams”), wat onze studiegroep hielp georganiseerd te blijven.
Maar sinds de recente this.router-fout de plugin brak, heb ik deze moeten uitschakelen - net als Ethsim2 - en nu is er geen gemakkelijke manier om onze agenda gesynchroniseerd te houden.
Als de officiële plugin het volgende zou ondersteunen:
Inkomende .ics-feeds (zelfs als de URL niet eindigt op .ics)
Update-detectie en optionele afhandelingsmogelijkheden voor het annuleren van evenementen
…dan zou Discourse een krachtig hulpmiddel zijn voor academische samenwerking. Het werkte perfect voor ons voordat de plugin brak - dus ik zou deze functionaliteit graag native zien landen.
niet vermeld omdat dit oorspronkelijk een gebruiker en hun sockpuppets waren. maar de accounts zijn samengevoegd en nu is het onderwerp verwarrend, aangezien de gebruiker heen en weer lijkt te posten met zichzelf.