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', int $user_id, array $login_context );

Example: record last-seen

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

Example: warm a per-user cache

add_action( 'mam_user_logged_in', function ( 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 ) );
} );

Related identity-lifecycle hooks

Gotchas

• App-only. WP-admin logins don’t fire this. Use wp_login if you need every login.
• $context shape varies by login source. 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