# Event posts: event dates, upcoming listings and past events

**URL:** <https://forum.ghost.org/t/event-posts-event-dates-upcoming-listings-and-past-events/63906>\
**Category:** Ideas\
**Created:** [October 3, 2026, 7:39am UTC](https://forum.ghost.org/t/event-posts-event-dates-upcoming-listings-and-past-events/63906 "2026-10-03T07:39:44Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Leo\_Perkins](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.ghost.org/leo_perkins/32/13279_2.png) [@Leo\_Perkins](https://forum.ghost.org/u/Leo_Perkins)\
**Post date:** [October 3, 2026, 7:39am UTC](https://forum.ghost.org/t/event-posts-event-dates-upcoming-listings-and-past-events/63906/1 "2026-10-03T07:39:44Z")

</div>

**Publish an event like a post. List it by when it happens.**

I’d like to propose **event posts** in Ghost: familiar posts with structured start and finish dates, a timezone, and location or booking details. They would use the existing editor and publishing workflow, while giving themes and integrations a reliable way to list upcoming and past events.

### The need

An announcement published in October for a December workshop should be visible straight away, appear in the right place in an event-date list, and move into past events after it finishes. Its publication date and event date serve different purposes.

Tagged posts, HTML cards and repurposed fields can help, but leave editors and theme developers maintaining workarounds for an everyday publishing task. Native event details would make that information easier to enter, validate and reuse.

### Who would benefit?

- **Creators and member communities:** live Q&As, workshops, launches and meetups that bring readers into direct conversation.
- **Local news publishers and newsletter writers:** upcoming activities readers can find in date order, with an archive of past events.
- **Nonprofits and community organisations:** volunteer activities, public meetings and learning opportunities, with clear information about when, where and how to participate.
- **Theme developers and integration builders:** consistent event data for listings and calendars, without parsing post content or borrowing unrelated fields.

My immediate use case is a theme for Landcare and community organisations, but I see this as a shared publishing need. Readable dates, participation options and access information help people decide whether and how they can attend. Ghost’s [recognition as a digital public good](https://ghost.org/changelog/digital-public-good/) provides relevant public-benefit context for serving independent publishers, nonprofits and civic organisations.

### A focused scope

The starting point would be event details attached to posts, plus reliable filtering and sorting by event date. Ghost would continue to handle content, newsletters and member access; booking and meeting services could handle registration and live sessions. Ticketing, attendee management and recurring-event rules could remain outside the initial scope.

There are related discussions on [adding events in Ghost](https://forum.ghost.org/t/how-to-add-events-in-ghost-cms/35317) and [event-date queries](https://forum.ghost.org/t/limiting-number-of-items-in-routes-yaml/47091), as well as community tools such as [Haunts](https://forum.ghost.org/t/testimonial-for-cathy-s-new-calendar-tool/63628). Native event details could provide a shared foundation for that work.

**Would event posts solve a recurring need for your publication? What do you organise, and how do you currently publish it in Ghost?**

I’d also welcome the Ghost team’s view on whether this scope fits the product direction. I can follow up here with a practical editor experience and a possible technical approach.

---

<div class="post-metadata">

**Author:** ![Leo\_Perkins](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.ghost.org/leo_perkins/32/13279_2.png) [@Leo\_Perkins](https://forum.ghost.org/u/Leo_Perkins)\
**Post date:** [October 14, 2026, 5:57am UTC](https://forum.ghost.org/t/event-posts-event-dates-upcoming-listings-and-past-events/63906/2 "2026-10-14T05:57:58Z")

</div>

I’ve now taken this proposal through to a working experimental implementation and published the modified core as **Ghost CMS + Events** :

[Public fork and implementation notes](https://github.com/landcare-design-system/ghost-cms-events)

The implementation is on `codex/event-posts-prototype`. There is also a [live demonstration at Banksia Coast](https://banksiacoast.com.au/tag/events/), using fictional community-organisation content.

The original distinction remains the centre of it: **publish the announcement when it is ready; list the event by when it happens.**

An event remains an ordinary Ghost post (`posts.type = post`), with `post_kind = event` and structured fields in `posts_meta`. Those fields cover start and finish, an IANA timezone, all-day dates, confirmed/cancelled/postponed status, location, and an optional booking URL and button label.

The working prototype includes:

- Event settings in the React editor, with local-time entry and UTC storage. All-day and multi-day events use calendar dates, including daylight-saving boundaries.
- Server-side event-date filtering and ordering through Ghost’s existing query mechanisms, before pagination. Upcoming/underway and past are derived from the finish time rather than a scheduled status update.
- Event details carried through duplication, local draft recovery and server-side revision history, with preview and restoration in the React editor.
- A public `.ics` download for published public events. It imports an event into a calendar; it is not a subscription that automatically receives later changes.

**The editor experience**

The event settings sit alongside the usual post settings. The publication date remains separate from the event dates, and the booking link, button text and status are editable fields.

 ![Ghost Admin event dates, timezone and all-day controls](https://us1.discourse-cdn.com/flex015/uploads/ghost2/original/3X/f/7/f7f8ca5c990c15bdb9f728bd98947306c0d4b76e.jpeg)

 ![Ghost Admin event location, booking link and status controls](https://us1.discourse-cdn.com/flex015/uploads/ghost2/original/3X/3/b/3be349c5b2beea8fd026ac30190e49f813a8bea8.jpeg)

Publication dates and existing post URLs retain their usual roles. Booking remains a link to an external service; I haven’t implemented ticketing, attendee management or recurrence.

I’ve also been exploring what a theme can do with those fields. The separate Landcare Design System theme, designed for Landcare organisations, renders the event details online and produces an A4 portrait flyer with a registration QR code. The code is generated locally from the booking URL, without sending it to a QR service. It’s useful for a community noticeboard as well as a website.

[Example event: Paperbark Creek Spring Planting Morning](https://banksiacoast.com.au/paperbark-creek-spring-planting-morning/)

 ![Event page with structured dates and registration link](https://us1.discourse-cdn.com/flex015/uploads/ghost2/original/3X/1/c/1cd08116cc5e62c912e59c9ecb0f607a96defc12.jpeg)

 ![Earlier DuneCare event print preview with registration QR code](https://us1.discourse-cdn.com/flex015/uploads/ghost2/original/3X/e/f/ef1db8eceb16162d450f26c31a096e9729d3037f.jpeg)

_Earlier prototype print preview, showing the flyer layout and registration QR code._

The public core fork does **not** include the Landcare Design System theme. The core supplies the event data and calendar endpoint; the theme supplies this presentation and print layout.

This is an evaluation prototype, not an official Ghost release or a production-ready upgrade. Focused event, API, editor and migration checks have passed, but the full repository test run is not clean. Legacy-editor support, creation/conversion flows, caching at event boundaries, and upgrade compatibility still need work. The repository documents those limitations.

**I’d welcome feedback on the implementation, particularly the metadata approach, all-day/timezone behaviour, and what would need to change for this to become a reviewable upstream contribution.**

For publishers, does the editor-to-listing-to-print workflow cover a practical need, or is there something essential missing?
