Purpose

Fires after a successful login through the mam-main app login flow (mam_login_manager::login_handler). Use for:

• Analytics (record login events)
• Last-seen / activity updates
• Post-login data warming (preload caches, sync external systems)
• Per-login one-shot actions (push token re-registration, etc.)

Distinct from WordPress’s native wp_login action — mam_user_logged_in fires only for app logins via mam-main’s flow, not for wp-admin logins.

Signature

do_action( 'mam_user_logged_in', array $data_array, int $user_id );

Note the argument order: the response $data_array is first, the user id is second.

Example: record last-seen

add_action( 'mam_user_logged_in', function ( array $data_array, int $user_id ) {
    update_user_meta( $user_id, 'mam_last_app_login', current_time( 'mysql' ) );
    update_user_meta( $user_id, 'mam_last_app_login_source', $data_array['source'] ?? 'email' );
}, 10, 2 );

Example: warm a per-user cache

add_action( 'mam_user_logged_in', function ( array $data_array, int $user_id ) {
    // Pre-build the per-user cache so the next phone-data request is fast.
    wp_schedule_single_event( time() + 5, 'my_plugin_warm_cache', array( $user_id ) );
}, 10, 2 );

Related identity-lifecycle hooks

Gotchas

• App-only. WP-admin logins don’t fire this. Use wp_login if you need every login.
• $data_array shape varies by login source. It is the response envelope, not a purpose-built context object — defensively check keys.
• Fires on every successful login, including silent re-auths from the app’s stored credentials. Don’t assume “first login” semantics — use mam_user_roles_after_create_user for that.
• Cloning admins log in as themselves, not as the cloned role. The is_cloning flag is set later via MAM_Current_Request.
• Cheap callbacks only. This runs in the auth path; slow subscribers add login latency.

Related articles

• Recipe: Customize onboarding
• Hook: mam_user_roles_after_create_user
• Content class: Login button

Metadata