Event page allows an unrealistic 10-year duration

[sabernhardt]

@dharmikpatel97 reported on ​#core65405:

This avoids assuming the end date is definitely wrong. It focuses on the observable behavior.

On the ​WordPress Credits Contributions event page, the event is displayed with a start date of 9 Apr 2026 and an end date of 9 Apr 2036, resulting in a duration of approximately 10 years and the message "Ends: in 9 years".

It is unclear whether this is an incorrect event configuration or a system issue that allows unrealistic event durations. The application should either prevent such durations through validation or clearly support long-running events if they are intended.

Steps to reproduce

• Open the WordPress Credits Contributions event page.
• Check the event details panel.
• Observe the start and end dates.

Actual result

Start date: 9 Apr 2026
End date: 9 Apr 2036
UI displays: "Ends: in 9 years"

Expected result

Event durations should be validated to prevent unintended multi-year spans, or the UI should clearly indicate that such long-running events are intentional.

[sabernhardt]

I think the events could continue to allow setting a long duration, but maybe the page could stop ​displaying the end date if it is more than one year (or so) in the future.

On the event details page, the end date and relative time (e.g. "Ends: in 9 years") are now hidden when the end date is more than one year in the future. Past end dates and near-future ones are unaffected.

Fixes https://meta.trac.wordpress.org/ticket/8280

## Summary

Makes the event end date optional, providing a semantically explicit way to model open-ended events (e.g. *WordPress Credits Contributions*) instead of relying on a fake far-future date.

This is an alternative to #676, which only hides the misleading "Ends: in 9 years" display when the configured end date is more than one year out — the underlying fake 2036 date persists. With this change, organizers can mark events as *Ongoing* via a checkbox; the end date meta is removed and the UI shows "Ongoing event" instead.

Fixes https://meta.trac.wordpress.org/ticket/8280

### Key changes

• Domain (Event): $end is now ?Event_End_Date; is_active(), is_past(), validate_times() are null-safe; new is_open_ended() helper.
• Repository: helper meta_query_end_after_or_unbounded() is applied to all current/upcoming queries so open-ended events (no _event_end meta) appear in current/upcoming lists. update_event_meta() deletes _event_end when null. get_event_meta() tolerates missing end.
• Cached repository: active-filter callback accepts null end.
• Capabilities: has_edit_field only modifies end when the event is past.
• Attendee_Adder: stats import clamps lookback to max(start, now − 1 year) for open-ended events to avoid unbounded SELECTs.
• Form: new "Ongoing event (no end date)" checkbox; the date input is disabled (so the browser doesn't POST a stale value) when ongoing.
• JS: checkbox toggles input state and skips end-date validation/WordCamp pre-fill when active.
• Display: details/list templates and the event-end theme block render an "Ongoing" label.
• RSS: <ev:enddate> is omitted for open-ended events.
• Legacy admin metabox: required removed and an empty value deletes the meta so admins can edit ongoing events from the WP Admin too.

### Backward compatibility

All existing events have _event_end set, so their behavior is unchanged. No migration required.

## Test plan

• [ ] Create a new event with the *Ongoing event* checkbox enabled — detail view shows "Ongoing event (no end date)"; _event_end meta is absent.
• [ ] Edit an existing event to open-ended — _event_end meta is deleted. Toggle back: meta is repopulated.
• [ ] An open-ended event with start in the future appears under *Upcoming*; with start in the past, under *Current*; never in *Past*.
• [ ] A bounded event with end < now continues to appear under *Past* (regression check).
• [ ] Host of an open-ended event can edit title/end after start.
• [ ] Attending an open-ended event with multi-year start does not run an unbounded translations scan.
• [ ] RSS feed (/events/rss) omits <ev:enddate> for open-ended events and remains well-formed.
• [ ] JS: toggling the checkbox enables/disables the end-date input and seeds a sensible default when unchecked.
• [ ] Cache: switching an active event between bounded and open-ended is reflected on the home page after the next request.