Action Triggers Runtime and API

The Action Triggers module lets BricksMembers react to arbitrary WordPress action hooks and turn those events into level assignments, enrollments, or group membership changes. In the current codebase, the runtime owner is src/Modules/ActionTriggers/ActionTriggersSystem.php and the canonical settings write owner is src/Services/ActionTriggersService.php.

Module Gate and Entry Points

• Module flag: brm_enable_action_triggers
• Bootstrap path: src/Bootstrap/BootstrapCoordinator.php → ActionTriggersSystem::boot()
• Admin surface: admin.php?page=brm_integrations&tab=action-triggers
• AJAX adapter: src/Ajax/ActionTriggersActions.php

Stored Trigger Shape

Triggers are stored in the brm_action_triggers option and normalized through ActionTriggersService. The normalized row keeps:

• uuid
• hook_name
• action_type = level, post_enrollment, or group_membership
• action = add, remove, enroll, or cancel depending on type
• level_id, post_id, or group_id depending on type
• group_role for group membership triggers
• use_current_user
• priority
• enabled

Runtime Binding

ActionTriggersSystem registers active triggers on init. Each enabled row creates a runtime add_action() binding for the configured hook name and priority. Invalid hook names are skipped after sanitization.

use BaselMedia\BricksMembers\Core\ModuleRegistry;
use BaselMedia\BricksMembers\Modules\ActionTriggers\ActionTriggersSystem;

if ( ModuleRegistry::is_active( 'action_triggers' ) ) {
    ActionTriggersSystem::boot();
}

User Resolution

The runtime can either use the current logged-in user or auto-detect a user from hook arguments. The detection path accepts numeric IDs, WP_User-like objects, objects with an ID field, values with a get_user_id() method, login strings, and arrays with a user_id key.

Supported Mutation Types

• Level actions: add or remove a BRM level for the resolved user
• Post enrollment actions: enroll or cancel enrollment for one configured post
• Group membership actions: add or remove the user from a configured group and role

Admin AJAX Surface

The admin UI persists triggers through these AJAX actions:

• brm_add_action_trigger
• brm_edit_action_trigger
• brm_delete_action_trigger
• brm_toggle_action_trigger
• brm_get_action_trigger

ActionTriggersActions stays thin. It validates the request and delegates normalization and persistence to ActionTriggersService.

Edit Guidance

• Start in ActionTriggersService when you need to change stored trigger shape.
• Start in ActionTriggersSystem when you need to change runtime binding or user extraction.
• Start in ActionTriggersActions only when the admin transport needs to change.