The Events module is the BricksMembers-owned runtime for scheduled member events, webinars, live classes, coaching sessions, Q&A sessions, and community events.
Primary Boundaries
- WordPress posts own authored event content through the
brm_eventcustom post type. - Events tables own event details, targets, registrations, attendance, provider connections, provider artifacts, and logs.
- Bricks Builder is a rendering surface only. It reads through Events query services, dynamic tags, and Bricks conditions.
- Payments module stays owned by the BRM billing system. Events uses offer keys for purchase gates and upsells instead of creating event-specific payment tables.
- Automations own outbound webhooks. Events emits automation triggers but does not own webhook delivery.
Canonical Owners
BrmEventService— canonical event write owner for CPT posts, event details, and targets.BrmEventQueryService— canonical read owner for event lists, single event payloads, counts, and admin tables.BrmEventRegistrationService— registration, cancellation, waitlist, and promotion writes.BrmEventAccessService— access, offer gate, registration, and join decisions.BrmEventCreatorPermissionService— admin, role, and group-owner create/manage scope decisions.BrmEventProviderConnectionService— encrypted provider credential storage and masking.BrmEventProviderOrchestrator— Zoom, Google Meet, and Microsoft Teams meeting lifecycle coordination.
Storage Contract
The CPT brm_event exists for Bricks template compatibility, SEO, archives, permalinks, authorship, and normal WordPress filters. High-volume and transactional data lives in targeted tables: brm_event_details, brm_event_targets, brm_event_registrations, brm_event_attendance, brm_event_provider_connections, brm_event_provider_artifacts, and brm_event_logs.
Query-performance repair is owned by BrmEventSchemaService and versioned by brm_events_query_perf_schema_version. Event calendar and registration reads should rely on indexed columns in brm_event_details and brm_event_registrations, including target/date/status and user/event registration composites. Public frontend requests skip strict schema metadata checks once brm_events_tables_created is present.
BrmEventQueryService owns request-local event read caching through RequestRegistry maps named event_rows, event_targets, and event_registrations. Mutation services must clear the relevant cache entries after event, target, or registration writes.
Do not add event-specific billing tables. Events uses the existing BRM billing system for purchase gates, upsells, checkout, fulfillment, refunds, and revocation.
REST API
The REST base is /wp-json/bricksmembers/v1/events. Event routes cover list, create, read, update, delete, register, cancel, join, registrations, attendance, provider connections, provider deletion, and provider connection tests. Management routes require Events capabilities; public reads and user registration routes still pass through access checks.
Bricks Builder Surface
Since version 1.1.1, Events use native Bricks post loops with post_type = brm_event for event lists and current-user registered events, plus native Bricks user loops for attendee lists. Dynamic tags use Bricks modifier syntax, for example {brm_event:title}, {brm_event:start}, {brm_event:join_url}, {brm_event:required_offer_key}, {brm_event:group_name}, and {brm_event_attendee:status}. Flat tag names such as brm_event_title are intentionally not registered.
Event Calendar Runtime
The BRM Event Calendar element and the admin Calendar tab use BrmEventCalendarAjaxController for feed, ICS, recurrence preview, and join transport. Calendar feeds stay on admin-ajax.php so the element works even when the optional BRM REST API module is disabled. BrmEventCalendarFeedService owns the sanitized read model, BrmEventCalendarRenderer owns server-rendered month/week/list/year markup, and BrmEventCalendarWeekLayoutService owns week-view overlap geometry.
Frontend event clicks are configurable in BRM_Element_Event_Calendar. The default built_in_detail mode opens the sanitized feed-based detail popup, single_event_link navigates to the event permalink, and bricks_popup calls Bricks’ popup runtime with the clicked brm_event post as context. Popup mode is presentation-only: registration, cancellation, join, ICS, and Google Calendar actions continue through the existing Events AJAX controllers and service owners.
Week events render with --brm-week-event-top, --brm-week-event-bottom, --brm-week-event-left, and --brm-week-event-width custom properties. Keep future layout changes in the week layout service or renderer; do not move feed filtering, access decisions, or registration mutations into calendar markup.
Provider Security
Zoom, Google Meet, and Microsoft Teams credentials are stored through the provider connection service. Secret values are encrypted at rest and masked in admin and REST responses. Submitting a masked value preserves the existing encrypted value. Provider adapters isolate remote API details from Events domain services.
For endpoint details and payload examples, see docs/dev-posts/events-api-reference.md and docs/feature-maps/events.md.