Compatibility contract

What an integration can depend on, what it must guard against, and what may change.

Stable

Safe to build on:

Content model

• the event post type;
• the event_type and event_category taxonomies, and shared post_tag;
• the meta keys event_start_date, event_end_date, event_start_datetime, event_end_datetime, hide_event_date, event_all_day;
• the pom meta array and the keys documented in Content model;
• event_assistants, keyed by user ID, with status values of empty, waiting-list and cancelled;
• attending_users, and the user meta attended_events.

Shortcodes

• [web_event_search_form] with hide_calendar, error_msg and el_class;
• [pom_events_fullcalendar] with el_class.

Filters

pom_events_settings · web_events_custom_meta · web_event_search_form · pom_events_assistants_table_headers · pom_events_export_users_content · pom_events_event_form_inputs · pom_events_single_meta_contact_number · pom_single_event_prev_next_args

Actions

pom_events_ajax_on_event_signup · pom_events_after_assistants_info_update · pom_events_assistants_table_columns · pom_events_single_before_main_block · pom_events_after_before_main_block · pom_events_single_details_before_place · pom_events_single_details_after_place · pom_events_before_single_content · pom_events_after_single_content · pom_events_single_before_related_posts · pom_events_single_after_related_posts

WooCommerce

• the cart item key event_id_to_enroll;
• the order meta associated_event_id.

Not stable

Do not build on:

• internal class and function names;
• admin screen markup and CSS classes;
• AJAX action names;
• generated asset paths;
• the internal storage layout of settings;
• the exact wording of user-facing messages, which follow translations.

Guards every integration needs

The theme gate. The event runtime only loads on the POM theme:

if ( ! post_type_exists( 'event' ) ) {
    return;
}

Optional features. Two parts of the model are conditional:

Code that assumes either will fail on sites that do not have them.

Optional meta. Treat every key in the pom array as possibly absent. Events saved before a field existed do not carry it.

Behaviors to design around

Enrollment happens on the thank-you page. A paid order does not guarantee an attendee. Reconcile.

Nothing is emailed. No confirmations, no notifications, no reminders. If your integration promises one, it must send it.

Capacity is not enforced on manual moves. An organizer can promote past the limit.

There is no recurrence. Each occurrence is its own event.

Deleting an event deletes its attendee data. There is no separate store.

Registrations create users. The attendee map is keyed by user ID.

Load order

Register integrations on init at a later priority, so the post type and taxonomies exist:

add_action( 'init', 'my_events_integration', 20 );

The settings screen, the license section and the updater load earlier and independently of the theme, so a settings-only integration does not need the theme guard.

Multisite

Everything is per site: events, attendees, settings and the enabled-features switches. Nothing is shared across a network.

When something changes

The changelog records behavior, API, dependency and release changes. Read it before updating an integration-heavy site, and re-run your own verification against the list of stable identifiers above.