Discourse Agenda bijgewerkt om fullcalendar 6 te gebruiken

Discourse calendar received a significant update today :rocket:. The core of the update is migrating from fullcalendar 4 to fullcalendar 6 which will bring us an updated UI:

We also used this opportunity to make the following changes:

  • Clean URLs for upcoming events page, eg: /upcoming-events/day/2025/8/2

  • Post event preview on click over an event

  • Performance has been vastly improved and having a large number of events should now be possible.

  • We now rely on the css variables provided by fullcalendar which should make the calendar work with your theme out of the box.

29 likes

Bravo, great job, thank you very much :heart_eyes:

2 likes

Klein vraagje, kunnen we (year) als standaard instellen voor het mobiele gedeelte?
Anders is het weer top!!

Thank you for the work ! Is both US/EU date format system supported for those url? and what if there are several events on the same day?

Sorry, we will support only one URL format for now.

That doesn’t prevent you from seeing all the events on this day/month/year. If you want to link to an event directly, link to the event post.

2 likes

Inderdaad kan de directe link naar het evenement worden gedeeld en het verstrekken van meerdere URL-formaten is geen gemakkelijke taak. We zijn al dankbaar dat u ons deze update voor fullcalendar 6 met nieuwe functies biedt!

1 like

Sinds de upgrade zie ik instanties van een verschil van 1 uur tussen de posttijd van het onderwerp (correct) en de kalendertijdweergave (een uur eerder) op sommige gebeurtenissen, maar niet alle.

Dit wordt ofwel opgelost nadat onze lokale tijdzone naar zomertijd overschakelt, ofwel worden sommige andere gebeurtenissen (omgekeerd) beïnvloed nadat de zomertijd begint. Niet alle gebeurtenissen worden echter beïnvloed. Is dit een bekend probleem? Is er een oplossing in de pijplijn?

Bug

This is brilliant! It really lifts the calendar to the next level.

I notice that the text of the event titles doesn’t wrap in the (default) Month view. Is this intentional?

Desktop Calendar

It would be nice to see the whole titles in the Month view on desktop (?perhaps on hover), as these are often packed with useful information. Of course, that would mean that the events could get greedy and take up more space.

Mobile Calendar

Also, in mobile it is rare to see more than the time. I guess this doesn’t matter so much as it is easy to tap them to see more.

An agenda view?

Lastly, it would be super helpful to have an agenda view, which is a common way of representing events. Is this at all possible via the calendar?

I know that it is doable using the Right Sidebar Blocks, but that is in a different context.

2 likes

Ja, ik zal dit vandaag repareren, ik wacht op een definitieve repro, bedankt.

3 likes

Should have been fixed by: FIX: removes support for include_expired param (#34582) · discourse/discourse@249ae00 · GitHub

1 like

I have a small suggestion:sweat_smile:
Instead of going to today’s date, wouldn’t it be better to go directly to the date of the next event?
It’s just an idea! :innocent:

Ik denk dat het algemeen verwacht wordt dat het vandaag opengaat. Als je je gebruikers aan een specifieke dag wilt koppelen, kun je nu de gewenste link maken: /upcoming-events/day/2025/9/2

Thank you!

Would following ISO date format be possible? As in YYYY/MM/DD (two digits for months and days)?

3 likes

Im mostly following what google is doing here:

Screenshot 2025-08-28 at 15.47.18

Ah, why would they follow standards when they can break it and create more work for others. :person_facepalming:

2 likes

Moeite om te begrijpen waarom /day/2025/09/01 zoveel beter is dan /day/2025/9/1

Ik zou stellen dat het slechter is om de nullen toe te voegen, omdat het meer ruimte inneemt in de balk.

Het is niet beter. Gewoon meer gestandaardiseerd en consistent met hoe datums in andere delen van Discourse worden gecodeerd.

Daarentegen is de manier waarop het momenteel is geïmplementeerd consistent met Discourse URL’s (die open-eindige nummering moeten hebben).

Dit is dus een filosofische beslissing. Interne consistentie met URL’s of interne/externe consistentie met datums. Er zijn voor- en nadelen aan beide. Ik geef de voorkeur aan de huidige implementatie.

If I would start write that date the form would be mm/dd. Because it is a standard practically everywhere — except when connection is from US and they would drop leading zeros and and start words with capital letters :smirking_face:. Or from coders who count spaces, because even americans can read and use mm/dd.

So, it is matter of muscle memory and a factoid that most of the word is used to use ISO format and it is hard to remember which software and platform uses which format. That is one of those questions where always someone loses — the question is which group is the biggest.

2 likes

Ha! Sorry, ik wilde niet over details discussiëren. Puur getallen worden numeriek gesorteerd, leidende nullen zorgen ervoor dat maanden in de juiste volgorde verschijnen.

3 likes

Ik zie nog steeds afwijkend gedrag van terugkerende gebeurtenissen voor en na lokale tijdswijzigingen naar zomertijd. We hebben een gehost abonnement, dus is het slechts een kwestie van wachten tot de oplossing is doorgevoerd?