BricksMembers handles external webhooks effectively but lacks native integration with internal WordPress events. Currently, simple tasks like granting a Level upon a Bricks Form submission, Role change, or lesson completion require third-party “glue” plugins or custom code snippets. Using a webhook loopback to trigger changes within the same site creates unnecessary overhead.

I propose adding a lightweight Action Triggers feature. This would function as a listener for WordPress Action Hooks to trigger Level assignments directly.

**Use cases:

1. Smart Role Mapping
User Roles are the standard integration point for the vast majority of WordPress plugins. By allowing BricksMembers to trigger level assignments based on Role changes, integration with third-party tools becomes significantly simpler without requiring specific add-ons.

Logic: If User Role becomes Editor -> Add Level Staff Access.

Benefit: It leverages the existing ecosystem where Roles are often the primary source of truth for user status.

2. Bricks Forms Integration
Bricks Builder forms include a “Custom” action that fires a PHP hook upon submission.

Workflow: A Bricks Form fires a custom hook (e.g., new_member_signup). BricksMembers detects this hook and assigns a specific Level.

Benefit: This enables custom registration and onboarding flows entirely within Bricks.

3. Learning Paths & LMS Features
Enabling BricksMembers to listen for specific hooks (e.g., when a lesson post type is marked complete) allows for the creation of learning paths. Completion of one content piece can automatically trigger the assignment of the next Level/Module.

4. E-commerce & Subscription Triggers
E-commerce plugins fire hooks on purchase and subscription events. Action Triggers would enable direct Level assignment upon purchase without requiring dedicated add-ons or webhook configuration.

**Implementation Suggestion
The interface should provide a simple text input field for the Hook Name and a selector for the Level to assign.

While a dropdown list of common presets (e.g., user_register, set_user_role) would be helpful for standard setups, it is crucial to allow custom text input for the hook name to support any third-party integration or custom development.

Note on User Context Handling:
For hooks that pass $user_id as argument, use that. For hooks without user context, fall back to get_current_user_id(). Optionally allow specifying which argument position contains the user ID.

Providing control over this context would make the feature robust enough to handle both background processes and frontend actions.

UPDATE: This will be added in version 0.9.5 🙂

expand

Hello,

I would like to use the access control feature for posts/pages, but in most cases I don’t currently use video addition, duration settings, or video images. I therefore suggest dividing the current content of the “General BRM Settings” box into several different boxes so that I can hide unnecessary elements and avoid confusing other website content managers, or adding the option to activate/deactivate these functions in the settings (ideally for each post type separately).

UPDATE: This will be added in version 0.9.5 🙂

expand