Login redirect

Overview

Configure the destination after a successful login. Select the subject with AAM::api()->login_redirect($access_level, $settings). Omit $access_level to use the current user or visitor.

PHP class: AAM_Framework_Service_LoginRedirect.

Method reference

Method	Purpose
`get_redirect()`	Read the effective redirect.
`set_redirect(array $redirect)`	Store a redirect model.
`reset()`	Remove one rule or all rules for this level.
`is_customized()`	Check for a direct rule or preference.

Return values vary by method. Rule updates usually return bool; reads can return a value, null, or an array. Errors follow the service’s error_handling setting and may produce WP_Error.

Accepted identifiers

This service has no resource identifier. set_redirect() takes a redirect model array for the selected access level; get_redirect() and reset() take no target. See the example below for the model shape.

Example

$redirect = AAM::api()->login_redirect('role:subscriber');
$redirect->set_redirect([
    'type' => 'url_redirect',
    'redirect_url' => '/account/'
]);

After a Subscriber signs in, AAM uses /account/ as the destination. The relative path keeps the redirect on this site.

Developer notes

Use a valid redirect model; get_redirect() resolves the effective configuration.
Call reset() to remove this level’s override and return to inheritance.
The selected access level determines whose rules are stored or evaluated. See Access levels.

Behavior and parameters

set_redirect($redirect) stores a redirect model; get_redirect() resolves the effective model; reset() removes the selected level’s override.
The model needs a type: default uses WordPress behavior, url_redirect uses redirect_url, page_redirect uses a page identifier, and trigger_callback uses a callable callback.
Use a relative path for an on-site destination. Test the actual WordPress event because the PHP framework stores the preference while the plugin handles the redirect during a request.