Developers

This chapter documents the stable, public surface of POM Events: the content model, the meta keys, the REST exposure, the shortcodes, the filters and actions, and the conventions integrations should follow.

In this chapter

The three assumptions to build on

The theme gates the runtime. POM Events only registers its content type, templates and shortcodes when the active theme's template is pom. Code that assumes the event post type exists must check, because on another theme it does not.

Dates exist twice. The editable datetimes live in the event's meta array; sortable Y-m-d values are derived and stored separately on save. Query on the derived values; read the datetimes for display.

Attendees are a meta array. Registrations are stored on the event as a map keyed by user ID, not in a custom table. That is why registering creates a WordPress user.

Stable identifiers

Safe to depend on:

• the event post type;
• the event_type and event_category taxonomies, plus shared post_tag;
• the price of admission for querying: event_start_date and event_end_date;
• the event_assistants and attending_users meta keys;
• the documented shortcodes;
• the documented filters and actions.

Not stable

Internal class names, admin markup, AJAX action names, generated asset paths and the internal shape of the settings storage. Build against what is documented here.

A note on the theme dependency

Guard every integration:

add_action( 'init', function () {
    if ( ! post_type_exists( 'event' ) ) {
        return;
    }

    // Safe to integrate.
}, 20 );

That single check covers both the theme gate and the load order, and it is the pattern used throughout this chapter.