[META] Track 7: Create "Events" recipe

I'm not sure what format is helpful for feedback here, but here are some thoughts, based on my own experience working with dates in Drupal, as well as looking at event handling in other calendar software from companies like Google, Apple, and Microsoft.

For the content entry, common widget patterns include:

• Inputting an event as a time range, with a concept of duration, so that setting the start time automatically sets the end, based on the duration
• Default time is the next hour (on the hour, no minutes or seconds)
• No seconds inputs
• An "all day" checkbox
• Ability to handle timezones (could be hidden by default)
• Ability to set an event as recurring (could be hidden or disabled by default)

For formatting the event dates and times, the solution should deduplicate parts of the date that are common to the start and end. For example, instead of output such as:
8:00am June 15, 2024 - 10:00am June 15, 2024

...it should create output like:
8:00 - 10:00am June 15, 2024

...or for date ranges:
June 15 - 17, 2024
June 30 - July 2, 2024

I would suggest that the recipe should also create an event listings page, including tabs for upcoming and past events. Perhaps it could also provide a block listing upcoming events, and automatically place it in the sidebar on the home page.

Many sites also want a calendar display, though it may not be necessary as part of the standard recipe. Having a calendar display as an available add-on would add value to the events recipe, however.

Looking at a comparison of WordPress event plugins suggest some other possible features, including:

• Registration (potentially including paid)
• Booking management, including approval and rejections
• Integration with calendar apps
• The ability to display the event location in a map
• Notifications/reminders before an event's start

I would suggest that these are more advanced features that don't need to be included in the standard recipe, but having them available within the broader ecosystem would be valuable.

Event content type should follow Google specified schemas as defined at:
https://developers.google.com/search/docs/appearance/structured-data/event

The event experience on Google makes it easier for people to discover and attend events through Google Search results and other Google products, like Google Maps.

In order to make it easy for a site builder to quickly apply a rich set of event management capabilities, it would be ideal if all available capabilities could be presented during the initial application of the recipes. As such, tagging as related a couple of issues around optional config and getting user input.

Love this idea and especially the notion of sub recipes.

One note on the calendar display idea, it would be great it it could handle things like showing a single event across multiple dates and give an option to put the all day and multi-events at the top (a la Google Calendar).

Just so I'm clear, when you say "Integration with calendar apps" you are referring to a button that allows for downloading an ical as well as automatically adding to google calendar, outlook calendar, etc. Just wanted to make sure this wasn't the same thing as mentioned in your first comment "Having a calendar display as an available add-on would add value to the events recipe, however."

It's worth pointing out that there was a long discussion thread related to this in Drupal slack:
https://drupal.slack.com/archives/C072BF486FN/p1719955373571009?thread_t...

I would be happy to lead this track, if it's still looking for an owner

Thank you @mandclu! Next week we will put out a formal call for folks who want to be a track lead, we will post the details in each issue so keep an eye out :)

🌱 Add an event listing to Umami (to show off core's datetime handling) Active is related. I’ll try to share more concrete thoughts on this when I can. Definitely important, and I have a lot of experience and opinions about Drupal’s date and event handling. 😅

Thanks!
-Derek

I'd like to help contributing to this track with a focus on the Calendar display. I suggest to use the Calendar View → which is compatible with core and smart_date but it needs work to improve the display of complex events (i.e. events spanning on several days, display as day with hours or agenda list...etc).

This track is an opportunity to improve this module and vice-versa!

@matthieuscarset I would love to consider Calendar View for use in Starshot, though I do have concerns that it doesn't yet have a Drupal 11-ready release. I would say that would be a top priority for a dialog about inclusion in Starshot.

One other potential consideration: Fullcalendar View offers drag-and-drop rescheduling of events by day, by hour, or even of the length of the event. If Calendar View can offer all of this it would significantly narrow the field.

I created a child issue to discuss the 'basic' event recipe scope: #3463884: Define scope of 'basic' event recipe that would be offered in the installer →

I think we'll want child issues for individual topics just so we can follow the threads.

I'm interested in this area, particularly where it bears on event registration and participation.

Registration is a very complex problem space, and I think the work done by @john.oltman in the contrib registration module is excellent. It allows registering while using any entity type as the event.

Similarly, as soon as you have events its common to want to give participants access to content partiular to that event, or give particular staff special privileges over that event. The group module is outstanding for this, but in the most straightforward scenario it requires the group entity to be the event.

My main contribution at this point is to point out that the question of what entity type the 'events' of this recipe have to be, is crucial to how useful this recipe is as a building block for more complex scenarios. It's easy enough to put together a basic events node type, but many projects will outgrow that and have to restart from scratch.

Perhaps there is a way that the recipe could focus on reusable packages like fields that could be applied to any entity type, or a way of wrapping any entity type as an event (which is what the registration module does, similar to how the typed_entity module does generically).

@jonathanshaw I agree that it would be ideal to choose a path forward that allows the most flexibility, and I also agree that the Registration module is a terrific solution on that front. I have an MR for making that module compatible with Drupal 11, so hopefully we can have a release soon.

I have also added to the issue summary to link to the projects where my proof-of-concept work to date are available, including a recipe that uses that module to add very basic registration. I would love feedback on what could be improved, and thoughts people have about what features should be included out-of-the-box in Starshot, versus available as add-ons.