UserAuth

33 hooks fired by UserAuth: 18 filters and 15 actions across 38 call sites. 24 of the 38 call sites are described by a docblock, at the call or on the constant that names the hook; the rest are listed with their signature and call sites only. Paths are relative to the plugin directory.

illegal_user_logins

Filter · 1 argument · 1 call site

Filters the list of usernames that may not be registered.

This is WordPress core's own filter, fired here a second time so that a username derived from the submitted email address can be tested before it is handed to wp_insert_user(). It is reached only when the registration form maps no user_login field, since that is the only case in which generateUsername() runs.

A match does not produce an error: both sides are lowercased for the comparison, and a hit makes generateUsername() substitute a random "xp_NNNN" name instead. Core fires the same filter in wp_insert_user() (wp-includes/user.php), so a callback registered for that check already applies here and needs no duplicate.

apply_filters( 'illegal_user_logins', [] )

• $illegal_logins (array) — Usernames that may not be used. Default empty array. Cast to array on return, so a non-array value is coerced rather than rejected.

Fired from:

• packages/UserAuth/Modules/Registration/Module.php:58

login_errors

Filter · 1 argument · 2 call sites

apply_filters( 'login_errors', __('<strong>Error:</strong> The username or password you entered is incorrect.', '{XPAC}') )
apply_filters( 'login_errors', $message )

Fired from:

• packages/UserAuth/Modules/Login/Module.php:121
• packages/UserAuth/Modules/Login/Module.php:144

new_user_email_content

Filter · 2 arguments · 1 call site

apply_filters( 'new_user_email_content', $email_text, $filterData )

Fired from:

• packages/UserAuth/Modules/Update/Module.php:113

xpac-forms-after-settings-modal-content

Filter · 3 arguments · 1 call site

Content appended inside a settings panel's item modal.

applyFilters( 'xpac-forms-after-settings-modal-content', [], { value: options, onChange: onUpdate, }, 'xpac-forms-user-auth' )

Fired from:

• assets/packages/user-auth/Settings/Components/Modal.js:398

xpac-forms-user-auth-action-settings-before-mapping

Filter · 3 arguments · 1 call site

applyFilters( 'xpac-forms-user-auth-action-settings-before-mapping', [], options, props.blocks )

Fired from:

• assets/packages/user-auth/Settings/Components/Modal.js:141

xpac_forms_user_auth_account_verification_for_users

Filter · 1 argument · 1 call site

Filters whether a signed-in visitor may use the account-verification flow.

All three of this module's guards read the same answer. The page guard in getPagesConfig() redirects a signed-in visitor to home_url() when it is false, handlePageRequest() answers the same page with a 404 instead, and execute() returns null so a resend-verification submission silently does nothing and reports success. The default is false, so the verification page and resend form are closed to other signed-in members. A user whose own pending token is in the request is allowed before this filter, and registration never auto-signs in a verification-required account.

Site managers never reach the filter: current_user_can('manage_options') returns true two lines earlier. Community Platform's Members\Pages\MemberOnly registers __return_true here, so on a site running that module the flow is open to every signed-in user.

apply_filters( 'xpac_forms_user_auth_account_verification_for_users', false )

• $accessible (bool) — Whether the flow is open to the signed-in visitor. Always false at this call site. There is no way to open one guard and not the others — a truthy return opens all three.

Fired from:

• packages/UserAuth/Modules/AccountVerification/Module.php:146

xpac_forms_user_auth_account_verified

Action · 1 argument · 1 call site

do_action( 'xpac_forms_user_auth_account_verified', $signup->user_id )

Fired from:

• packages/UserAuth/Modules/AccountVerification/Module.php:287

xpac_forms_user_auth_activation

Action · 0 arguments · 1 call site

Fires once when the User Auth plugin is activated, after the framework's own activation work has finished.

This is the package's install hook and the only point at which schema work is safe, because it runs exactly once per activation rather than on every request. AccountVerification\Database listens here to CREATE the xp_signups table, and Modules\Bootstrap listens to build its module set so the other components exist while the table is being created.

A listener must not assume it was registered before the action ran. Database's constructor guards with doing_action() for this hook and creates the table inline instead, because on the activation request the object can be built after the action has already fired.

No arguments are passed.

do_action( 'xpac_forms_user_auth_activation' )

Fired from:

• packages/UserAuth/Bootstrap.php:37

xpac_forms_user_auth_activation_email_failed

Action · 2 arguments · 1 call site

do_action( 'xpac_forms_user_auth_activation_email_failed', $userId, $error )

Fired from:

• packages/UserAuth/Modules/Registration/Module.php:335

xpac_forms_user_auth_allow_registration

Filter · 2 arguments · 1 call site

Filters whether a registration form may create an account.

Defaults to WordPress's own Settings → General → "Anyone can register". Return true to keep an invite-only flow working with that option off.

apply_filters( 'xpac_forms_user_auth_allow_registration', (bool) get_option('users_can_register'), Helper::submissionForExternalCallback($submission) )

• $allowed (bool) — Whether registration is open.
• $submission (Submission) — A callback-safe clone without credential answers.

Fired from:

• packages/UserAuth/Modules/Registration/Module.php:101

xpac_forms_user_auth_can_grant_role

Filter · 3 arguments · 1 call site

Filter whether a user may grant a role through a User Auth form action.

apply_filters( 'xpac_forms_user_auth_can_grant_role', $canPromote && [] === array_diff_key($granted, $held), $userId, $role )

• $canGrant (bool) — Whether the user may promote accounts and holds every capability of the target role.
• $userId (int) — User doing the granting.
• $role (string) — Role slug.

Fired from:

• packages/UserAuth/Core/Roles.php:62

xpac_forms_user_auth_email_change_confirmation_url

Filter · 1 argument · 1 call site

apply_filters( 'xpac_forms_user_auth_email_change_confirmation_url', $fallbackUrl )

Fired from:

• packages/UserAuth/Modules/Update/Module.php:119

xpac_forms_user_auth_email_change_lifetime

Filter · 1 argument · 1 call site

apply_filters( 'xpac_forms_user_auth_email_change_lifetime', DAY_IN_SECONDS )

Fired from:

• packages/UserAuth/Modules/Update/Module.php:174

xpac_forms_user_auth_email_update_confirmed

Action · 1 argument · 1 call site

do_action( 'xpac_forms_user_auth_email_update_confirmed', Helper::userForExternalCallback($user) )

Fired from:

• packages/UserAuth/Modules/Update/Module.php:230

xpac_forms_user_auth_enforce_verification

Filter · 1 argument · 1 call site

Filters whether an unverified account is refused everywhere, not just on a form whose "verified account only" toggle is on.

Login\Module attaches the same guard around its own wp_signon() call and removes it immediately afterwards, so it covered neither wp-login.php, nor XML-RPC, nor application passwords, nor a second form with the toggle off. Only accounts holding an unactivated signup row are affected, so accounts that never entered the verification flow — including every account that predates it — sign in unchanged.

apply_filters( 'xpac_forms_user_auth_enforce_verification', true )

• $enforce (bool) — Whether to refuse unverified accounts site-wide.

Fired from:

• packages/UserAuth/Modules/AccountVerification/Module.php:70

xpac_forms_user_auth_forgot_password_fail

Action · 3 arguments · 1 call site

Fires when a forgot-password submission names an address with no account.

This is the lookup failure, before any mail is attempted: get_user_by('email') found nothing, so $user is always false here. That is what separates this hook from xpac_forms_user_auth_user_forgot_password_fail, which fires when the account does exist but retrieve_password() refused. execute() returns a WP_Error immediately afterwards, which aborts the submission at the pre-submit stage, so no entry row is written and no notification is sent.

do_action( 'xpac_forms_user_auth_forgot_password_fail', $user, Helper::userDataForExternalCallback($userData), Helper::submissionForExternalCallback($submission) )

• $user (false) — Always false — the failed result of the get_user_by('email') lookup.
• $userData (array) — The mapped non-credential user fields. Only user_email is read here.
• $submission (Submission) — A callback-safe clone without credential answers.

Fired from:

• packages/UserAuth/Modules/ForgotPassword/Module.php:88

xpac_forms_user_auth_form_settings

Filter · 2 arguments · 1 call site

apply_filters( 'xpac_forms_user_auth_form_settings', $storedItems, $submission->forExternalCallback() )

Fired from:

• packages/UserAuth/Modules/Bootstrap.php:522

xpac_forms_user_auth_redirect_url

Filter · 3 arguments · 2 call sites

Filters where a visitor is sent after signing in through a form.

Consulted only as the last fallback. A _wp_http_referer field on the submission wins outright, and the form's own redirect settings win next, so this runs only when neither is set. The ?: on the call replaces any falsy return with home_url(), so returning null keeps the default rather than disabling the redirect.

The registration module fires the same filter with $action set to "new_user"; there a falsy return leaves the form's redirect config untouched instead of substituting home_url(), so the two call sites do not behave alike on a null.

Community Platform's Account page listens here and returns the member account page URL, but only for the "login" action.

Filters where a visitor is sent after registering through a form.

Consulted only when the form's own redirect settings are off or have no success URL, and only a truthy return is used — unlike the login call site, a falsy return here leaves the form's redirect config exactly as it was rather than substituting home_url().

The closure holding this call is registered on xpac_forms_redirect_config and therefore runs after execute() has returned, which is what decides the third argument: if "log in after registration" was on, it is the new account, and if it was off it is the anonymous WP_User with ID 0. A listener that builds a per-member URL must check the ID rather than trust it.

Community Platform's Account page listens here but returns early unless $action is "login", so it does not affect this call site.

apply_filters( 'xpac_forms_user_auth_redirect_url', null, 'login', Helper::userForExternalCallback($user) )
apply_filters( 'xpac_forms_user_auth_redirect_url', null, 'new_user', Helper::userForExternalCallback(wp_get_current_user()) )

• $url (string|null) — Proposed target. Always null here.
• $action (string) — Which auth action is redirecting. Always "login" at this call site.
• $user (WP_User) — A callback-safe clone of the user who just signed in.

Fired from:

• packages/UserAuth/Modules/Login/Module.php:222
• packages/UserAuth/Modules/Registration/Module.php:303

xpac_forms_user_auth_referer

Filter · 1 argument · 1 call site

Filters the value printed into a login form's _wp_http_referer hidden field.

insertHiddenFields() runs on xpac_forms_after_form_begin for every rendered form that carries a login action, and prints the returned value immediately below as a hidden input named _wp_http_referer. Nothing else in the package populates that field, so this filter is the only way to set it.

The return is treated as untrusted at both sinks: insertHiddenFields() applies wp_validate_redirect() and esc_attr(), and Login\Module::execute() validates the submitted value again before returning it to the browser. An off-host or malformed value is ignored in favour of the form's normal redirect settings.

apply_filters( 'xpac_forms_user_auth_referer', null )

• $referer (string|null) — URL to submit as the post-login redirect target. Always null at this call site; any falsy return prints no field at all, which leaves the form's own redirect settings in charge of where the visitor lands.

Fired from:

• packages/UserAuth/Modules/Bootstrap.php:740

xpac_forms_user_auth_reset_password_page_slug

Filter · 1 argument · 1 call site

Filters the page slug that stands in for wp-login.php in the password-reset flow.

Read on two separate paths. handlePageRequest() passes it to is_page() on every front-end request, and an empty slug makes that guard return early — so with no slug the reset page is never 404ed for a visitor with no reset in progress and the wp-resetpass cookie is never set from a ?key=&login= link, which is what makes the form work at all. ForgotPassword's changeResetPasswordLink() uses the same value to rewrite the link in the outgoing reset mail, with a plain preg_replace of the literal "wp-login.php" in the message body, so the return value has to be a bare slug: a path such as "account/reset" survives into the mail but will not satisfy is_page(), which compares against post_name alone.

The unfiltered value is the post_name of the page chosen in the Reset password page setting, or an empty string when no page has been chosen.

apply_filters( 'xpac_forms_user_auth_reset_password_page_slug', $slug )

• $slug (string) — Page slug with no leading or trailing slash. Empty when the setting is unset or points at a deleted page. Returning a slug with no matching page produces reset mail pointing at a 404.

Fired from:

• packages/UserAuth/Modules/ResetPassword/Module.php:58

xpac_forms_user_auth_reveal_accounts

Filter · 1 argument · 1 call site

Filters whether User Auth may confirm an account exists.

apply_filters( 'xpac_forms_user_auth_reveal_accounts', false )

• $reveal (bool) — Whether to answer differently for a known address.

Fired from:

• packages/UserAuth/Core/Helper.php:149

xpac_forms_user_auth_send_new_user_notifications

Filter · 1 argument · 1 call site

apply_filters( 'xpac_forms_user_auth_send_new_user_notifications', true )

Fired from:

• packages/UserAuth/Modules/Registration/Module.php:238

xpac_forms_user_auth_token_lifetime

Filter · 1 argument · 1 call site

apply_filters( 'xpac_forms_user_auth_token_lifetime', 2 * DAY_IN_SECONDS )

Fired from:

• packages/UserAuth/Modules/AccountVerification/Module.php:245

xpac_forms_user_auth_user_create_fail

Action · 3 arguments · 1 call site

Fires when a registration action's wp_insert_user() call fails.

The codes are core's, most often existing_user_login, existing_user_email or empty_user_login. No account row exists. Duplicate-account failures become the same accepted public response as registration when account disclosure is disabled; this trusted hook still receives core's diagnostic WP_Error.

do_action( 'xpac_forms_user_auth_user_create_fail', $userId, Helper::userDataForExternalCallback($userData), Helper::submissionForExternalCallback($submission) )

• $userId (WP_Error) — The failure wp_insert_user() returned. Named $userId because it holds the return value of the call that would otherwise be a user ID.
• $userData (array) — The rejected $userdata array with credentials removed; mapped meta remains under meta_input.
• $submission (Submission) — A callback-safe clone whose password and confirmation answers have been removed.

Fired from:

• packages/UserAuth/Modules/Registration/Module.php:171

xpac_forms_user_auth_user_created

Action · 3 arguments · 1 call site

Fires immediately after a registration action has created the account.

The user row is already committed and cannot be rolled back, but nothing else has happened yet: the activation email has not been sent, core's new-user notifications have not been sent, and auto-login has not run. A listener that needs the account to be usable — profile fields, group membership — belongs here. Later activation-mail failure is reported as accepted-with-warning and leaves a recoverable pending account rather than turning this committed write into failure.

Community Platform listens twice: Notifications::sendWelcomeNotification() takes one argument and suppresses core's own new-user mail by returning false from xpac_forms_user_auth_send_new_user_notifications, and ProfileFields\UserRegistration::saveProfileFields() takes two and writes the submitted profile fields against the new account.

do_action( 'xpac_forms_user_auth_user_created', $userId, Helper::userDataForExternalCallback($userData), Helper::submissionForExternalCallback($submission) )

• $userId (int) — ID of the account just created.
• $userData (array) — The committed $userdata array with credentials removed; mapped user meta remains under meta_input.
• $submission (Submission) — A callback-safe clone whose password and confirmation answers have been removed.

Fired from:

• packages/UserAuth/Modules/Registration/Module.php:215

xpac_forms_user_auth_user_forgot_password

Action · 3 arguments · 1 call site

Fires after a password reset link has been mailed successfully.

retrieve_password() has already generated the key, stored its hash in the account's user_activation_key and sent the mail, with wp-login.php in the link swapped for the configured Reset password page slug by changeResetPasswordLink(). Nothing after this point can fail the submission, so a listener may treat the reset as issued.

Forms stores the accepted submission afterwards. It may retain the submitted address according to the form's normal entry settings; credential answers are always removed before that boundary.

do_action( 'xpac_forms_user_auth_user_forgot_password', Helper::userForExternalCallback($user), Helper::userDataForExternalCallback($userData), Helper::submissionForExternalCallback($submission) )

• $user (WP_User) — A clone of the account with its password hash and reset-key material blanked.
• $userData (array) — The mapped non-credential user fields.
• $submission (Submission) — A callback-safe clone without credential answers.

Fired from:

• packages/UserAuth/Modules/ForgotPassword/Module.php:159

xpac_forms_user_auth_user_forgot_password_fail

Action · 3 arguments · 1 call site

Fires when the account exists but WordPress could not issue a reset link.

retrieve_password() returned a WP_Error: the site blocked the reset through allow_password_reset, no reset key could be stored, or wp_mail() refused the message. Contrast xpac_forms_user_auth_forgot_password_fail, which fires when no account matched at all. The same WP_Error is returned to the visitor as the submission result, so the submission aborts and nothing is logged.

do_action( 'xpac_forms_user_auth_user_forgot_password_fail', $errors, Helper::userDataForExternalCallback($userData), Helper::submissionForExternalCallback($submission) )

• $errors (WP_Error) — The error retrieve_password() returned. Its code is core's, commonly retrieve_password_email_failure or no_password_reset.
• $userData (array) — The mapped non-credential user fields.
• $submission (Submission) — A callback-safe clone without credential answers.

Fired from:

• packages/UserAuth/Modules/ForgotPassword/Module.php:133

xpac_forms_user_auth_user_logged_in

Action · 3 arguments · 2 call sites

Fires after a login action has authenticated the visitor.

wp_signon() has already set the auth cookie and the current user, so is_user_logged_in() is true here and wp_get_current_user() returns $user.

The registration module fires this same hook name when "log in after registration" is on (Registration/Module.php), so a listener sees both paths and must not assume the account already existed. Fires before this module attaches its xpac_forms_redirect_config callback. Forms stores the accepted submission afterwards with all credential answers removed.

Fires after a new registrant has been signed in automatically.

Reached only when the action's "log in after registration" toggle is on. The previous session has been cleared and wp_set_current_user() plus wp_set_auth_cookie() have already run, so the new account is the current user.

This is the same hook name the login module fires, so a listener sees both a returning member and a brand-new account and must not assume either. The registration path reaches it only when verification is not required; pending accounts are deliberately never auto-signed in.

do_action( 'xpac_forms_user_auth_user_logged_in', Helper::userForExternalCallback($user), Helper::userDataForExternalCallback($userData), Helper::submissionForExternalCallback($submission) )
do_action( 'xpac_forms_user_auth_user_logged_in', Helper::userForExternalCallback(get_user_by('id', $userId)), Helper::userDataForExternalCallback($userData), Helper::submissionForExternalCallback($submission) )

• $user (WP_User) — A clone of the now-authenticated user with password hash and reset-key material blanked.
• $userData (array) — The action's mapped user fields with user_pass and user_current_pass deliberately removed.
• $submission (Submission) — A callback-safe clone whose password and confirmation answers have been removed.

Fired from:

• packages/UserAuth/Modules/Login/Module.php:170
• packages/UserAuth/Modules/Registration/Module.php:269

xpac_forms_user_auth_user_login_fail

Action · 3 arguments · 1 call site

Fires when a login action's wp_signon() call fails.

The codes reachable here are core's empty_username, empty_password, invalid_username, invalid_email and incorrect_password, plus this package's own unverified_account when the form has "verified account only" on and account verification is enabled. Fires before execute() normalizes an invalid-account error, so the code and message seen here are exactly the ones wp_signon() produced.

do_action( 'xpac_forms_user_auth_user_login_fail', $user, Helper::userDataForExternalCallback($userData), Helper::submissionForExternalCallback($submission) )

• $user (WP_Error) — The authentication failure wp_signon() returned.
• $userData (array) — The action's mapped user fields with user_pass and user_current_pass deliberately removed.
• $submission (Submission) — A callback-safe clone whose password and confirmation answers have been removed.

Fired from:

• packages/UserAuth/Modules/Login/Module.php:103

xpac_forms_user_auth_user_reset_password

Action · 3 arguments · 2 call sites

Fires after a password change has been accepted.

The forgotPassword flow reaches this call only after wp_update_user() has committed the new password and the reset cookie has been cleared. Update\Module fires the same hook after a current-password-authenticated profile change has committed, so listeners may treat either call site as a durable password-change boundary.

Forms stores the accepted submission afterwards with all password and confirmation answers removed.

do_action( 'xpac_forms_user_auth_user_reset_password', Helper::userForExternalCallback($user), Helper::userDataForExternalCallback($userData), Helper::submissionForExternalCallback($submission) )

• $user (WP_User) — A callback-safe clone of the reset key's owner.
• $userData (array) — The action's mapped user fields with both password values removed.
• $submission (Submission) — A callback-safe clone whose password and confirmation answers have been removed.

Fired from:

• packages/UserAuth/Modules/ResetPassword/Module.php:328
• packages/UserAuth/Modules/Update/Module.php:437

xpac_forms_user_auth_user_reset_password_fail

Action · 3 arguments · 1 call site

Fires when the password write of a forgot-password reset fails.

wp_update_user() returned a WP_Error. The reset key and the new password had already passed every check this module makes, so the failure is core's or another plugin's, and the account still holds its old password. The same WP_Error is returned as the submission result, which aborts the submission at the pre-submit stage — no entry row is written and no notification is sent. The error object itself is not passed to listeners.

The wp-resetpass cookie is deliberately retained on failure so the visitor may correct a transient write problem without requesting a fresh email.

do_action( 'xpac_forms_user_auth_user_reset_password_fail', Helper::userForExternalCallback($user), Helper::userDataForExternalCallback($userData), Helper::submissionForExternalCallback($submission) )

• $user (WP_User) — The account whose password could not be written, resolved from the reset key by check_password_reset_key().
• $userData (array) — The action's mapped user fields with both password values removed.
• $submission (Submission) — A callback-safe clone whose password and confirmation answers have been removed.

Fired from:

• packages/UserAuth/Modules/ResetPassword/Module.php:297

xpac_forms_user_auth_user_update_fail

Action · 3 arguments · 2 call sites

Fires when an update action's wp_update_user() call fails.

The codes are core's, most often existing_user_email or invalid_user_email. Nothing has been written to the account, and the WP_Error is returned to the visitor as the submission result, so the submission aborts.

The reset-password module fires this same hook name when its own wp_update_user() call fails, so a listener must not assume the update action.

do_action( 'xpac_forms_user_auth_user_update_fail', $error, Helper::userDataForExternalCallback($userData), Helper::submissionForExternalCallback($submission) )
do_action( 'xpac_forms_user_auth_user_update_fail', $userId, Helper::userDataForExternalCallback($userData), Helper::submissionForExternalCallback($submission) )

• $userId (WP_Error) — The failure wp_update_user() returned. Named $userId because it holds the return value of the call that would otherwise be a user ID.
• $userData (array) — The rejected $userdata array with credentials removed. It is already reduced: empty values have been stripped by array_filter, ID is the signed-in user, mapped meta sits under meta_input, user_email is absent when the action confirms email changes, and user_current_pass is absent when it confirms password changes.
• $submission (Submission) — A callback-safe clone whose password and confirmation answers have been removed.

Fired from:

• packages/UserAuth/Modules/ResetPassword/Module.php:216
• packages/UserAuth/Modules/Update/Module.php:403

xpac_forms_user_auth_user_updated

Action · 3 arguments · 1 call site

Fires after an update action has saved changes to the signed-in user's account.

wp_update_user() has already committed the profile fields, the password and — when the action does not confirm email changes — the new address. Any confirmation mail has been queued by this point, so a pending address change is not yet reflected in the account and will only appear once the member follows the link.

Community Platform's ProfileFields\UserRegistration::saveProfileFields() listens here with the same two-argument callback it uses on xpac_forms_user_auth_user_created.

do_action( 'xpac_forms_user_auth_user_updated', $userId, Helper::userDataForExternalCallback($userData), Helper::submissionForExternalCallback($submission) )

• $userId (int) — ID of the updated account, which is always the currently signed-in user.
• $userData (array) — The applied $userdata array with credentials removed, after array_filter stripped empty values. user_email is absent when the action confirms email changes, so its presence here does not mean the address changed.
• $submission (Submission) — A callback-safe clone whose password and confirmation answers have been removed.

Fired from:

• packages/UserAuth/Modules/Update/Module.php:467