Content model
The post type, its taxonomies, and where event data lives.
The post type
| Property | Value |
|---|---|
| Slug | event |
| Public | Yes, publicly queryable, with an archive |
| Rewrite base | event |
| Hierarchical | No |
| Supports | title, editor, author, thumbnail, excerpt, custom-fields |
| REST | Enabled, base event |
Registration is gated by the active theme: on a theme whose template is not pom, the post type is not registered. Always check with post_type_exists( 'event' ).
Taxonomies
| Taxonomy | Structure | Rewrite | REST base |
|---|---|---|---|
event_type |
Hierarchical | event_type |
event_types |
event_category |
Hierarchical | event_category |
event_categories |
post_tag |
Flat, shared with posts | post_tag |
Core |
post_tag is the site's normal tag taxonomy, registered for events as well. A tag archive can therefore contain both events and posts.
Where event data lives
Two layers, and the distinction matters:
The pom meta array holds the editable values from the event panel:
event_start_datetime · event_end_datetime · date_format · event_place · introductory_text · organized_by · available_button_label · custom_hashtag · contact_number · additional_links · waiting_list_button_label · finished_event_button_label · optional_form_fields · available_space
Derived and standalone meta written on save:
| Key | Contents |
|---|---|
event_start_date |
The start as Y-m-d, for querying and sorting |
event_end_date |
The end as Y-m-d |
event_start_datetime |
The start datetime |
event_end_datetime |
The end datetime |
hide_event_date |
The per-event date-hiding switch |
event_all_day |
The all-day switch |
event_assistants |
The registrations map |
attending_users |
Attending user IDs |
Why dates exist twice
The datetime values are what an editor enters and what templates print. The Y-m-d values are normalized on save specifically so they can be compared and sorted in a meta query.
Query on event_start_date and event_end_date. Display from the datetimes. See Event query recipes.
The attendees map
event_assistants is an array keyed by user ID:
$assistants = get_post_meta( $event_id, 'event_assistants', true );
// [
// 42 => [
// 'email' => 'person@example.com',
// 'comments' => 'Vegetarian',
// 'tel' => '+34 600 000 000',
// 'country' => 'Spain',
// 'status' => '', // '' | 'waiting-list' | 'cancelled'
// ],
// ]An empty status means confirmed. That is why registering creates a WordPress user: the key of this map is a user ID.
attending_users holds an array of user IDs, and user accounts additionally carry an attended_events meta array of event IDs.
Reading an event safely
$meta = get_post_meta( $event_id, 'pom', true );
$start = $meta['event_start_datetime'] ?? '';
$place = $meta['event_place'] ?? '';
$start_day = get_post_meta( $event_id, 'event_start_date', true ); // Y-m-dTreat every key as optional. Events created before a field existed, or saved without it, simply do not carry it.
Writing event data
The pom array is written as a whole by the editor. If you must write to it programmatically, read it, modify the key, and write it back — and update the derived event_start_date and event_end_date if you changed the datetimes, or queries will disagree with the page.
Statuses
Events use ordinary WordPress statuses. Public listings query publish.