🗓 Discourse Event

Absolutely we are all for collaboration, I think we need about 1-2 months first to get through our roadmap. Once that is done we can start talking about taking contributions for things that are missing (pending approval ™).

In the mean time, if anything feels to you missing from our roadmap please let us know. The roadmap is not set in stone. Happy to answer stuff here and adjust as needed.

We are taking this extension quite seriously, @joffreyjaffeux has been working on it mostly full time for the past few weeks and will continue to do so till we reach our stopping point.


Great. We’re consolidating some feedback and reviewing the use cases we’re aware of. We’ll raise any product level stuff here, and keep the more technical stuff on github.


awesome work!

Not sure if this is related to the plugin, but whenever I try to open the link from somewhere thats not in the hamburger menu, the calendar view doesn’t show up.

The following methods of accessing the page didnt work:

  • putting the link to /upcoming-events into the Header Links Theme Component
  • putting the link to /upcoming-events into the Easy Footer Theme Component
  • typing the link directly into my browser

Here’s what i see when using any of the three methods above:

& heres what I see when I inspect… the element with id of events-calendar doesn’t have any children and no attached classes, like this.

Tried in two browsers:
Brave: Version 1.7.92 Chromium: 80.0.3987.163 (Official Build) (64-bit)
Safari: Version 11.0.2 (12604.

& one thing to note is that my forum is private

sometimes the calendar view does work when i click on the “Upcoming Events” item in the hamburger menu. The html looks like this in those cases, has children and some additional classes.

I’m using the Minima Theme with some additional customization in the CSS. I’ve also tried with some of the standard themes that come out of the box but encountered the same issue.


Do you have any plugins installed? I’m having this problem as well (except mine happens when I go via the hamburger menu), but if I go into safe mode with non official plugins disabled the calendar shows up every time, so it seems to be a plugin conflict.


The upcoming events page bugs should be fixed by:

I tested that the link was correctly showing, that I could directly link to it from a post and that a hard refresh was working.

If it’s still not working for you, please give me a detailed reproduction and the list of plugins/themes you use.


Nice work. Really interesting to see an alternative implementation of the events use case :heart_eyes:

2 things.

  1. Currently, composer allows adding more than 1 event but considers only the one that appears first as the event.
  2. The icon for event and calendar are somewhat difficult to distinguish between.

Hi, thanks,

Probably wont change this, this is very edge case, and it’s visible than the second one is not working, so worst case you try once and see you can’t. I might display something at some point, but I don’t consider this important for now.

Well yes it’s very similar stuff, so similar icons are kinda expected. What icon would you use ? I think I had a clock for dates at the very beginning and people didn’t like it, I also tried a globe.
My plan is maybe removing the need for the date button some day (I think you name it calendar, but you mean date).


What I’d like to see on the roadmap:

  • provide interface for users to get a subscription link for calendar apps
  • display events in emails

Also nice to have:

  • allow/disallow events in category
  • make events mandatory for new topics in category

Both of these will probably be worked on this week.


Awesome! I’ve finally had a chance to take a closer look at this plugin. This is super exciting - nice work! I also really appreciate how @angus and the pavilion team are jumping on board with helping make this official plugin great so communities can transition to it from Events Plugin 📆. Loving this developer community. :revolving_hearts:

  • Some sort of migration tool from Events Plugin 📆 would be a big help for sites that are now depending heavily on that plugin. Maybe this could be a one-off rake task?
  • “Discourse Event” is easy to confuse with Events Plugin 📆 - we will be getting support requests here for the wrong plugin. I’m not sure how to address that at this point except maybe to just move all the event stuff into the calendar plugin topic and stop referring to “Discourse Event”? Add notes in the OP here and there explaining the difference? :man_shrugging:
  • Icon on the upcoming events link on the hamburger menu is nice, but looks a bit lonely if it’s going to be the only link on the menu with an icon. I’d suggest removing it and allowing sites to style their own hamburger menu links if they want to decorate with icons.
  • Upcoming events calendar looks empty and boring when there are no events scheduled for the month on display. For those communities where there are not lots of events, it would be helpful to be able to easily switch to an agenda view with a list of upcoming events in chronological order, a la google calendar. Also the ability to filter by category, and have the colors match category colors like Events Plugin 📆 does so nicely. I also am missing the event popups which were so handy to learn more about an event before committing to leave the calendar and open the topic.
    • also, minor bug? emoji are not displaying correctly on the upcoming events calendar
  • I’d love to see 24 hour time support, maybe settable as a user preference. Not everyone uses AM/PM.
  • Is this feature being designed mostly for internal use, eg for people already within a community, or is it also going to be possible for guests without accounts to RSVP and get event reminders? If so, events can be a great way to grow a community, e.g. by inviting people to a webinar or face to face event.
  • To be a proper eventbrite killer, the ability to ask questions (what are you bringing, etc) or allow comments while people RSVP would be pretty amazing.

Why wouldn’t you use the posts for this ?

The API allows it, for our internal board for example this is certainly not the only link with an icon. Also settings and admin have an icon.

For the upcoming page, there are tons of work to do, this is the simplest possible thing I could do for now.

I have already started working on this

It will eventually be possible, we are trying to have a customer with this use case to use it to have real feedback on this.


Sure. I guess that is an option. You can then also use polls and checklists in the topic. But my experience has been that more people will provide info if they are asked questions in an event registration form rather than asked to reply with info.

This is all shaping up wonderfully. You are doing a great job with a complex bit of functionality! :ferris_wheel:


I can’t imagine doing this not using posts ATM, although one thing we could do is asking a question which would open the composer.

But I might need more questions examples, maybe some classic questions could be treated differently.


Real life examples:

“We hope you’ll join the weekly update meeting. Please let us know what topic(s) you would like the group to consider for discussion.”

“Please reply to this topic and provide a short written update on your projects’ status before the staff meeting.”


Yes thanks, both are solved elegantly by using posts IMO.

It’s only a matter of making it easy.


@joffreyjaffeux After looking more closely at the code and functionality, I just want to reiterate that I like what you’ve done here :slight_smile:

For example, I was initially worried about the use case of editing an existing event, which I thought might need to be done via markdown. However you’ve added that neat menu for the cooked content. Nice work.

Here are some initial thoughts on the current plugin and roadmap.

Event v Date v Calendar

If you just install the discourse-calendar plugin (and nothing else), there are three types of time-related items you can add to a Discourse composer, [event], [calendar] and [date]. The use cases for these, and how they interact, are getting a little muddled if you’re not already familiar with the plugins themselves and Discourse in general.

For example, the existing discourse-calendar plugin requires you to create [dates] in posts in the same topic as the [calendar]. This [event] feature set (which is in the same plugin), requires you to create [events], which are different from [dates], but also are added to a calendar that looks exactly the same as the topic-specific [calendar] which included the [dates], but acts quite differently.

I’m also wondering about the “legibility” of this from a code perspective. Reading the code I found it somewhat tricky to keep all the “Event” and “Calendar” classes and methods straight in my head. If someone was coming to the code blind in 2 years time I think they may find it hard to follow, not because it’s poorly written, but just in terms of naming.

As the code of the Discourse Event features is already somewhat seperate from that of the Discourse Calendar features, I’m wondering if it’s feasible to make these two seperate plugins to allow for a bit more clarity around their functionality and use? In any event, interested in your thinking about this distinction on both a product and code level and where it’s heading. This will help us think through how we help people migrate from the events plugin as well.

Somewhat relevant to this is some thoughts around the rendering of the calendar itself (see below). If the new [event] functionality were separated from the use of full-calendar I wonder whether it would continue to make sense to keep it in the discourse-calendar plugin.

Composer UX

Relatedly, for many of the current users of the events plugin, further clarification will be needed on the [event] / [date] distinction in the composer UI. The icons and terms used are essentially synonymous to most users, and the controls for both are in essentially the same place. I’m not sure this issue is remedied by putting the Events button in the gear menu.

If you’re reticent to change this, I’m wondering if there could be a way to address this via a theme component in relevant cases. I wonder if there’s a stable way to allow other parts of the composer to interact with the toolbar / markdown, which would allow a kind of composer UI like the events plugin currently has in cases where the current UX is an issue.

Category permissions

The Events Plugin is largely structured around categories in response to the use case(s) of various communities. The most frequent structure we’ve seen with the events plugin is a seperate “Events” category, or sometimes multiple events sub-categories. The site-wide events calendar (which is also possible with the events plugin) or agenda is relatively rare.

The scoping of events in this plugin is currently mostly built around groups, and I understand this in response to the use case(s) this was built for. Most use cases of the events plugin I’ve seen are not in communities with defined user-groups however.

I don’t see category-specific permissions on your roadmap so I’m wondering how open you are to a PR in that respect.


I’m wondering about the use cases for having a seperate title for the event, different from the topic title, given you can only create events in the first post of a topic. Could you explain this a bit?

One potential issue I can see with this (without understanding more about the use case) is that there can be a mis-match between the title associated with the date/time in the topic list and site header and the title you see in the event item in the topic.

Screen Shot 2020-05-05 at 11.36.30 AM
Screen Shot 2020-05-05 at 11.37.47 AM

When the event is exported to different clients via .ics files or feeds I’m assuming the custom title (if it exists) will show up there?


There’s currently no explicit timezone support. I’m sure you’ve considered this, so I’m wondering what your thinking is here? Will it be similar to the timezone handling for [dates]?

Time formatting

One of the most frequent requests I got over the years with the events plugin was the ability to format the time and timezones for events in different ways.

After trying a few different approaches, I found the best way of handling this is by allowing the user to supply a moment-js format pattern via site settings. I can see this working with the structure you’ve built. Is that something you’re already thinking about, or would be open to a PR on?

All day events

Currently, the plugin doesn’t support all day events without start and end times. The issue with multi-day events with specific start and end times is that people don’t want the event taking up large portions of their calendar.

Are there any plans to allow for this in the future? I can see it being worked into the markdown options, however I’m wondering about the roadmap here, given that there are already site settings to add default times to events without times.

Event Sequence

I’m wondering if/how you’re planning to manage event sequences given that you’re supporting .ics files and or ical feeds. There’s some discussion of the relevant RFCs here (once you get past the discussion about UIDs), with some useful input from others, including @md-misko:

If you’re going to add event sequencing what’s your thinking on what qualifies for a sequence increment? See further RFC 5546 - iCalendar Transport-Independent Interoperability Protocol (iTIP)


Currently you’re using full-calendar to render the calendar. This is fine for some basic use cases however you run into limitations with it for a number of Discourse-relevant use cases. One of the out-of-the-box limitation is the responsive/mobile view, which affects a significant % of users.

As an example, I’ve added three events on June 1 in a mobile calendar in the current Discourse Events plugin. Firstly, the height is fixed, so I actually don’t see them on initial load. Then when I scroll inside the calendar element I see

This is the same set of events in the current Events plugin mobile view (no scroll inside the calendar element required)

It’s not straightforward (or sometimes possible at all) to handle responsive issues with full calendar. It’s not without cause that you’ll find a fair bit of chatter about issues with full calendar on mobile devices and various “mobile friendly” forks.

In addition to responsive view, other limitations of using full calendar that come to mind include the ability to easily add additional controls (such as feed links), fine-grained control over style and easy to control event popups.

If I was going to suggest you adopt anything from the events plugin it would probably be a version of the calendar components. They’re already isolated components set up to work with Discourse, and they’re probably the most stable part of the events plugin. I haven’t changed them in a long time. I’d be willing to adapt them to this plugin if you’re open to a PR along those lines.

Plugin outlets

In addition to perhaps having a way to add controls to other parts of the composer that allow you to stably interact with [event] markdown another integration point that is relevant to various use cases we currently support is the ability to add other details to events.

The most common use case is adding locations to events via the Locations Plugin. The events and locations plugins already play nicely together as they essentially have the same structure (they were actually originally going to be one plugin, until I realised that was a bad idea…).

A basic version of this kind of integration should be relatively straightforward, assuming it’s possible to add a plugin-outlet to the post-event template. Would that be doable?

Things we could help with (summary)

To summarise, these are some things we’ve initially considered we could help with:

  • Usability modifications to the composer UX, perhaps via the api or other integration hooks if possible.

  • Adding category-specific permissions

  • Time formatting in topic list items and in post event details.

  • Improving the calendar, particularly the responsive version, potentially by using the existing events plugin calendar components.

Also open to suggestions on areas we could potentially help with, i.e. other things I haven’t listed above, but you’re considering.


It’s been made this way for a smoother transition while we find an implementation we like. The goal being to have only one way to create events in the ends, and ofc you will still be able to display dates.

I don’t understand what’s your proposal here.

No PR for now please, I’m not against this but don’t want to rush this for now.

I will see how it’s used, I’m not super attached to this. To be honest when I added this I had in mind to be able to have multiple events per topic and even per post, we back pedalled on this but didn’t remove it. I thought it would be nice, but maybe won’t be used, we will see.

Yes it’s written on the roadmap to allow people to create events with another timezone as reference. And probably a lot of other stuff to handle down the road…

Yes I have seen this requested, this is very easy to do, I just don’t want to focus on this for now. I don’t see this as something refraining adoption and more a nice to have, so no hurries. Could accept a PR on this.

I’m working on it this week.

I will change how we do cal sync, I’m waiting for a core commit from @david and will then rethink all of this, I have no particular insights on this ATM, but the reads were interesting thanks.

Yes agreed, and I didn’t detail it, but this is part of the changes I want for this page. I haven’t discussed of this with @sam yet. I’m not interested in using discourse-events component at this point as there are quite a lot of things I want to do differently, as far as I can see it seems you are more or less trying to implement something close to what basecamp calendar does, which is also more or less my target.

post-event is a widget, so no plugin outlets, but I could add decorators or even a dedicated API, this kinda tricky because we want a fixed height to prevent topic jumpyness. We can definitely envision this at some point, and I’m more interested in making this work with your plugins than direct PRs. I’m unsure what we are going to do about locations at this point, I think having the location in the OP probably solves mosts use cases, I imagine only very few use cases need to have all the events displayed on a map so I’m unsure…


Basically, some sites may have UX issues with having the events button in the composer toolbar. Some folks will need a bigger and more prominent button, outside of the composer toolbar.

The easiest way to accomodate this kind of need is probably through a theme component. I’ve added buttons outside of the composer toolbar that successfully interact with composer markdown wizards in the past, for example this is a theme component that adds a poll builder button to the composer footer.

I’d like to be able to do the same here, ideally without the jiggery-pokery you see in that theme component, i.e. sending the whole toolbar to the composer controller so I can access it in a composer outlet.

This may be outside the scope of this project per se, however it would help us roll this out to more current events users. Perhaps I could make a PR along these lines to Discourse that allows you to do this generically, seperate from this.

Thanks for the other clarifications and notes. I’ll get back to your re locations once I’ve had more of a chance to test the interaction.


Thanks for clarifications, I see the concern, but definitely out of scope for now, at least as far as this plugin is concerned.


For recurring events, such as daily or weekly meetings, this could be nice and create less “topic clutter”. In other words, one topic for the meeting series, and a separate event/post for each instance that may have a unique topic/theme.

Right now we are doing this by creating a new topic for each week, e.g., “Staff Meeting 2020 W-15”, but I could imagine it’d be much cleaner if we we just had a general running “staff meeting” topic that people could respond to with meeting notes or agendas for the latest meeting. Having everything in one neat topic is especially valuable when one meeting builds on the content from the previous meeting.