Problem/Motivation

Umami is here to show off the cool things you can do with core.
Events are an incredibly common need in websites of all sorts.
Currently, core's datetime handling is all kinds of broken (says someone who's unofficially helping to co-maintain it -- no offense meant to anyone -- Dates Are Hard(tm)).
To "eat our own dogfood" on this, let's try to have an event listing in Umami.
That'll help us realize how bad our datetime handling is, and give focus and purpose for fixing those limitations.

Beyond #bugsmash and #dogfood, a food magazine might want to offer readers info about various events, both IRL and online:

  • Cooking classes.
  • "Meet the author" or "Meet the chef" events.
  • Food/drink festivals
  • ...

Proposed resolution

  1. Add an 'Event' node type.
  2. Have an 'Events' menu item that leads to an event listing/view for end users.
  3. Add something (another view) for admins to review pending events, moderate, manage, etc.
  4. Fix core's date handling enough to make this actually usable and slick. ;)

Remaining tasks

  1. Start trying to do this with current core.
  2. Identify limitations and link them to this plan as related issues.
  3. Smash the bugs.
  4. Add the features.
  5. Circle back to Umami and make it work.
  6. Reviews / refinements / improvements.
  7. RTBC.
  8. Commit.
  9. Feast on large pile of home-grown dogfood! ;)

User interface changes

New 'Events' menu item and 'Event' node type in Umami demo profile. Details TBD.

API changes

None directly.

Data model changes

Not sure how this applies to a profile issue. New node type, fields, etc.

Release notes snippet

TBD.

Comments

dww created an issue. See original summary.

dww’s picture

Issue summary: View changes

Clarifying a few views I think this would need.

mandclu’s picture

I'm notoriously opinionated about datetime and some other admin UI issues, so I'll chime in a few thoughts, based on what I would consider best practices:

  • I agree with having a view specifically for managing events, but I also think that whenever possible we should give admins and editors the opportunity to manage or add least add to content in the public view. So long as permission are followed, there's no reason they should have to go to a completely separate interface. For example, including something like #3133235: Make views "add content" link for specific bundle, option for custom text
  • I strongly dislike the way core's datetime range forces a user to manually enter a value for every field, unless using a default that often isn't useful (e.g. now or now + offset). With no default on a standard datetime range field, you would need to manually populate 14 fields for a single range (if using am/pm). The calendar software most people are used to have a concept of duration (@dww I know you and I have discussed this previously) with a default (e.g. one hour), so that having entered the starting set of values, the end set can be populated automatically, and tweaked if necessary
  • For typical applications (e.g. meetings) the inclusion of the seconds value isn't helpful
  • As a default, now or "now + offset" aren't what people encounter in common calendar applications. Usually it's more like "next hour"

I will also add that I created the Smart Date Starter Kit as a way to package together what I consider best practices as an easy-to-manage configuration for events. If we want a contrib space to hammer out some ideas on what we think a "best of breed" solution could look like, that (or something similar) could work as a place collaborate on ideas and make them tangible before getting into the work of moving the final changes into core.

markconroy’s picture

I like this idea (speaking as a maintainer of Umami).

I don't know enough about dates/date fields/date range/etc to be a great help (except I know how frustrating it is to try set up event content types as a site builder.

The only item of issue I have here is that after a while all the events will be out of date as time passes, so we need to figure out some way to put (at least some of the events in the future). Maybe part of the migration script for installing Umami can set the dates for specific events as one one, one week, one month, two months, etc from "now".

mandclu’s picture

Great point about being able to create event with an offset from the time of installation. Maybe this script could also be used to manually "refresh" event date so they're recent or upcoming rather than in the distant past.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

markconroy’s picture

I wonder should we mark this issue as 'Postponed' for two reasons:

1. It doesn't look like any one has worked on it since it was created 2 years ago, and
2. We don't have an events content type in Umami so it would be impossible to create an events listing.

dww’s picture

1. True. ;) no one wants to put their hand in the blender on this one.

2. The intention of this issue would be to add events and an event listing. That’s not a reason to postpone this issue. No one would agree to an issue to “add events to Umami” if there was no listing of them or way to browse them. This is the issue for both (if we’re ever going to try eating our own dog food on this topic). 😅

Anyway, I’m not sure postpones makes sense. It’s not blocked on anything, other than time and interest.

Thanks,
-Derek

markconroy’s picture

That sounds fair @dww.

I'll leave it as is for now so and if someone feels like firing up the blender later, we'll be waiting with open arms (and bandages).

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.