The Member Profiles feature set covers profile-page user resolution, custom profile fields, privacy export integration, and Bricks Forms account-management actions. The current runtime bootstrap owner is src/Modules/MemberProfiles/MemberProfilesFeatureRegistrar.php.
Module Gate and Entry Points
- Module flag:
brm_enable_member_profiles - Bootstrap path:
src/Bootstrap/BootstrapCoordinator.php→MemberProfilesFeatureRegistrar::boot() - Admin page:
admin.php?page=brm-profile-fields - Profile resolver:
src/Services/ProfilePageService.php
Profile Page Resolution
ProfilePageService owns the configurable detection cascade used by profile pages and profile-aware dynamic tags. It supports these detection modes:
currenturl_paramauthorurl_param_author
It also registers the query vars brm_profile_user and brm_profile_user_id, plus rewrite rules for profile-style routes when URL-param detection is enabled.
Field Visibility and Directory Query Support
ProfileFieldRuntimeBridge owns field visibility, privacy export registration, and the Bricks user-query filters that protect private-owner rows from leaking into public directories.
wp_privacy_personal_data_exportersbricks/users/query_varsbricks/query/resultbricks/query/result_countbricks/query/result_max_num_pages
Since 0.9.94, ProfileFieldFilterIntegration also exposes a Bricks Query Filter source named brmProfileField. It adds the profile-field picker to Bricks filter elements, builds filter option payloads from the current user query result set, and maps submitted filter values onto WP_User_Query meta queries. It only exposes filterable field types and checks the configured visibility before returning options or applying filters.
Checkout Custom Profile Fields
Member Profiles owns only the custom profile-field configuration for checkout. The field config may include checkoutAvailable and checkoutMapping, persisted with the normal brm_profile_fields option by ProfileFieldsPage and ProfileFieldsHandler. Payments must not store a second profile-field definition. WordPress-native buyer fields such as email, display name, first name, and last name are handled by the Payments checkout customer-details runtime instead of being duplicated as custom profile fields.
The Payments module consumes that config through CheckoutProfileFieldsRuntime and renders it through profile-field rows inside BRM Checkout Fields. Each checkout field row stores its source and concrete field key, so a checkout can render only the custom profile fields chosen for that element instance and keep them ordered with other checkout fields. Supported checkout types are text, textarea, email, URL, number, date, select, and checkbox. Image/upload fields remain account-profile fields only because checkout handoffs must be JSON-safe and retryable across hosted provider flows. Profile fields are rendered only through BRM Checkout Fields; there is no separate checkout profile-fields element in the current checkout architecture.
The only system checkout mapping currently exposed by Member Profiles is group_name. It is valid for text fields only and now acts as a fallback for older profile-field-based group-name setups. New native Payments checkouts can use the first-class group/team name field from BRM Checkout Fields. When either value is present on a successful native Payments checkout, the billing/group provisioning path can use the sanitized value as the initial group name while still writing mapped profile-field values to the user’s profile field after payment succeeds.
Bricks Forms Account Actions
Frontend account mutations are exposed through Bricks Forms integrations under src/Integrations/BricksForms/. The current feature set includes profile edit, password change, email change, avatar upload, custom fields, privacy settings, export, and account deletion.
Admin Surface
ProfileFieldsPage renders the field editor and ProfileFieldsHandler processes saves. That admin transport is separate from runtime profile resolution and query filtering. Checkout-specific toggles are stored on the same field config and normalized through ProfileFieldRuntimeBridge; Payments only reads the normalized config at checkout time.
Edit Guidance
- Start in
ProfilePageServicefor route-resolution and user-detection changes. - Start in
ProfileFieldRuntimeBridgefor visibility, directory, privacy-export behavior, or checkout field eligibility/mapping normalization. - Start in
CheckoutProfileFieldsRuntimewhen the change affects checkout rendering payloads, checkout request sanitization, post-payment profile writes, or checkout system mappings. - Start in
ProfileFieldFilterIntegrationfor Bricks profile-field Query Filter behavior. - Start in the specific Bricks Forms integration when the change affects an account form action.