Opened 6 weeks ago
Last modified 6 weeks ago
#8280 new defect (bug)
Event page allows an unrealistic 10-year duration
| Reported by: | sabernhardt | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Translate Site & Plugins | Keywords: | has-patch |
| Cc: |
Description
@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.
Change History (3)
This ticket was mentioned in PR #676 on WordPress/wordpress.org by @khokansardar.
6 weeks ago
#2
- Keywords has-patch added
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.
This ticket was mentioned in PR #683 on WordPress/wordpress.org by @ocean90.
6 weeks ago
#3
## 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):$endis now?Event_End_Date;is_active(),is_past(),validate_times()are null-safe; newis_open_ended()helper. - Repository: helper
meta_query_end_after_or_unbounded()is applied to all current/upcoming queries so open-ended events (no_event_endmeta) appear in current/upcoming lists.update_event_meta()deletes_event_endwhen null.get_event_meta()tolerates missing end. - Cached repository: active-filter callback accepts null end.
- Capabilities:
has_edit_fieldonly modifies end when the event is past. Attendee_Adder: stats import clamps lookback tomax(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-endtheme block render an "Ongoing" label. - RSS:
<ev:enddate>is omitted for open-ended events. - Legacy admin metabox:
requiredremoved 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_endmeta is absent. - [ ] Edit an existing event to open-ended —
_event_endmeta 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 < nowcontinues 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.
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)
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.