LoginPress Redirect Login - WordPress Plugin

How to Configure Login Routes with LoginPress Redirect Login

This guide to LoginPress Redirect Login will help you assign different pages after login and logout, prepare user roles and destination URLs, create a clear journey for visitors, and test it without putting administrator access at risk. Rather than discussing redirects in the abstract, we will follow the working path from a WordPress account to the page a user actually sees after signing in successfully.

LoginPress handles this task through its Login Redirects add-on. It lets you set a destination after login and logout for a selected user or role. An editor can land on a work page, a customer can go to their account area, and a subscriber can enter a members-only section without being dropped into the standard WordPress dashboard. The main rule of this guide is simple: first plan the intended path and a fallback way to access the site, then enable the rule, and only then test it with a separate account.

A post-login redirect is part of access behavior, not form decoration. Choosing the wrong page can confuse users, pull them away from a paid course, send customers into an administrative area, or make it look as though sign-in failed. A well-planned rule, on the other hand, turns authentication into a short path to the next action. That is the practical value of LoginPress Redirect Login: routing can live in the settings instead of being scattered across the theme, widgets, and separate code snippets.

When a post-login route is genuinely useful

Default WordPress behavior does not suit every site. An owner or editor will usually expect the dashboard, but a store customer, learner, community subscriber, or private-portal client generally expects to continue on the public-facing side of the site. When everyone is sent to the same place, users have to find the section they need on their own. On a small site, that is merely an extra step. On a site with account areas, courses, orders, or different roles, it quickly becomes a support issue: someone signs in, sees an unfamiliar page, and does not know what to do next.

LoginPress Redirect Login is appropriate when a role has a repeatable next task. A customer returns to My Account, a subscriber opens a resource section, an editor goes to an internal instruction or reporting page, and a portal employee enters their own work area. Importantly, the add-on does not grant permissions or replace WordPress roles. It only chooses a destination after WordPress has already confirmed the credentials and applied the user's capabilities. For that reason, first decide who can access the page, and only then make it the landing point.

Use cases where a rule provides clear value

The clearest example is an online store. After login, the Customer role receives the account-page URL, where orders, addresses, and profile details are available. The customer does not encounter WordPress administrative items or spend time looking for the right section. This is especially helpful when the "Log In" link is in the site header while authentication still happens through a standard WordPress page styled with LoginPress.

Another common use case is a site with protected content. A subscriber signs in to read resources or continue learning, not to edit the site. A welcome page, lesson catalog, or personal collection is a natural destination. If you use LifterLMS, LoginPress documentation describes a separate redirect section that appears when the LMS is installed and active. Its destination routes can be organized around instructors, courses, and members. That is not a reason to enable the integration unnecessarily, but it is a good example of why the route should follow the user's goal.

A third case is an internal team site. There is no reason to send everyone to one home page: an author may need a task board, an editor may need content awaiting review, and an administrator may need the standard dashboard. However, the more exceptions you create, the more important it becomes not to replace a user-role model with a collection of disconnected rules. First create a clear role model, then apply shared rules to groups and reserve personal assignments for truly exceptional cases.

Who the add-on suits and when another approach is better

The add-on works well for a WordPress site owner who already uses LoginPress and wants to manage destinations through the interface. It is convenient for an editor who needs to change a landing page quickly without deploying a custom modification, and for a project where an entire role needs the same route. It is also useful when rules should apply after logout: for example, when a visitor should return to a regular public page rather than remain on an inaccessible URL after ending a session.

Do not choose this solution as a replacement for access architecture. If a page must be protected, its protection should be handled by permissions, a membership plugin, an LMS, or WordPress capabilities. A redirect does not turn a public page into a private one. It is also not the right tool for a dynamic rule such as "return every user to exactly the page they came from" for any arbitrary URL: the documentation describes assigning URLs by user and role, not a universal builder for previous-page behavior. In that case, first check what the active form, the redirect_to parameter, and other plugins do, then decide whether a separate development solution is needed.

What to define before you start configuring

Before opening the dashboard, it helps to write down a simple map. The first column contains a role or a specific account. The second contains the reason that person signs in. The third contains the destination after login. The fourth contains a safe page after logout. This map prevents guesswork and immediately exposes risky points: a page without the required permissions, a draft, a temporary address, a protected section without a proper login form, or a route that leads back to the login form itself.

Example route map before enabling LoginPress Redirect Login

Who	Next action after login	Suitable destination	What to verify separately
Customer	View an order or profile	Store account page	Data is visible only to the current user
Subscriber	Continue reading or learning	Starting members-only section	Access works correctly after authentication
Editor	Move to an editorial task	Internal page or dashboard	Role capabilities and absence of unnecessary privileges
Special user	Open a personal area	Individual URL	Whether it conflicts with the role rule

This table does not replace configuration, but it gives you a testing criterion. If you cannot explain in one sentence where a person should land and why, the rule is not ready to be enabled. It is especially important to preserve a separate path for an administrator who can sign in and reverse an unsuccessful assignment. The easiest approach is to create a regular non-privileged test account and avoid testing a customer route in your own administrator session.

How LoginPress Redirect Login chooses a destination page

The most useful way to think about the add-on is as a rules layer that runs after the username and password have been validated successfully. The inputs are a specific WordPress user, their roles, the addresses stored in LoginPress settings, and possible conditions imposed by other site components. LoginPress Redirect Login then matches the user to an applicable rule and passes the assigned address to the browser. The visible outcome is a new page after login or logout. Understanding this sequence matters because it helps distinguish a routing issue from an authentication, access-permission, or caching issue.

The add-on interface documents the Specific User and Specific Roles tabs. In the first tab, you find an account through the username search field, see its ID, username, and email address, then provide a Login URL and Logout URL. In the second tab, you select a site role and set the same addresses for the group. Each row includes Update and Delete actions, so a rule can be changed or removed without rebuilding the entire settings set from scratch.

Login, rule, state change, and visible outcome

You can picture the sequence this way: the user submits the login form - WordPress validates the credentials - the system knows the account and its capabilities - the add-on finds an applicable assignment - the browser receives an address - the user opens the intended page. Do not confuse two different outcomes in this chain. Successful authentication means that a session has been created. A redirect means that an already authenticated user has been sent to another URL. If the form reports a password error, configuring Login URL is pointless. If sign-in succeeds but the wrong page opens, investigate the rule, the role, the URL, and other redirect handlers.

This breakdown also helps with site support. Instead of saying "the plugin does not work," you can record a specific observation: under a customer account, login completes, but the browser opens the standard WordPress area instead of the account page. That is a testable hypothesis. First check whether the add-on is active, then whether a rule exists for the Customer role, whether the address was saved, whether the destination page exists, and whether another plugin is interfering. The same sequence works for logout, except that you need to test Logout URL in a clean browser session.

When to choose a role and when to choose a specific user

A role rule is the main option for a repeatable use case. If every customer should arrive at the same account page, choose Customer and assign its URL. When new customers appear every week, the administrator will not need to create a rule for each of them. This approach is easier to test and maintain because the connection between access and routing is visible at the role level rather than disappearing among personal exceptions.

A specific user is appropriate when one person genuinely needs a different path. That could be a tester, an editor with separate instructions, a manager with a personal page, or an account owner who has temporarily been given an individual route. But a personal rule should not compensate for an unclear role model. If such exceptions become numerous, pause and ask whether a new permanent group of users has emerged and would be better served by a role or a separate access mechanism.

Be particularly careful with accounts that have multiple roles. WordPress can store more than one role for a user, and the site may have additional plugins with their own rules. LoginPress documentation clearly shows role selection and URL configuration, but do not build a critical route on an assumption about the order of several matches unless you have tested it in a staging environment. For a key audience, it is better to keep one clear destination role or use a carefully tested personal rule.

Why you should not choose a destination based on the page title alone

An "Account" page may be visible in a menu, but that does not prove it works correctly after login. Check its permalink, published status, role requirements, and behavior in a new session. If it is a store page, make sure it displays the current customer's data rather than a general storefront. If it is an LMS section, make sure the learner can actually see the course they are entitled to access. For an internal page, check that it does not expose administrative actions to users without the necessary capabilities.

It is safer to enter a full address only after you have tested it in a browser. Do not place a local-environment address on a live site, carry a temporary domain over after a migration, or leave a test-page URL in the rule. The rules form contains separate fields for login and logout, so an incorrect address may appear at only one of those moments. Record assignments in your route map and change them deliberately instead of editing a dozen rows at once.

Working with redirect_to and other handlers

WordPress uses the redirect_to parameter to pass a desired page in a login link. It is often useful when an unauthenticated person tries to open a specific protected URL and should return to the original task after signing in. A permanent assignment in LoginPress Redirect Login solves a different problem: it sets a route for a selected user or role. If a site simultaneously uses a store form, membership plugin, LMS, login protection, two-factor authentication, and custom code, they may all participate differently in choosing the final address.

For that reason, do not test a new setting only through a link with a prefilled redirect_to. First test a normal sign-in through the standard form, then a login from a real user path, then a protected page, and finally logout. If the expected outcomes differ, record which component should take precedence. For an ordinary customer route, preserving the store's behavior is usually more useful. For a permanent corporate portal, one predictable role rule may be the better choice. One setting does not have to be correct for every login path.

Quick takeaway: LoginPress Redirect Login routes an already authenticated user. Good diagnosis starts by separating four questions: did login succeed, which role does the account have, which rule applies to it, and is the specified page available in a new session?

Prepare your WordPress site before enabling a rule

Preparation takes less time than investigating a redirect loop. Start with a site copy or at least a period when changes will not disrupt visitors. For a simple role rule, this does not require complex development: carefully check the roles, destination pages, and one test account. If the site is connected to a store, courses, or a private community, add a test order, course enrollment, or content entitlement to the plan, because the fact that login succeeds does not prove the next step works correctly.

Also determine who controls access. LoginPress Redirect Login should not duplicate restrictions defined by another system. For example, a membership plugin may send a guest to a form, an LMS may send them to the appropriate course, and WooCommerce may send them to the account area. Your task is to determine which component controls access, which chooses the destination page, and which merely styles the form. A clear division of responsibilities reduces the risk of two settings competing for the same route.

Pre-configuration checklist

• Verify that the main LoginPress plugin is installed, active, and opens in the dashboard without errors.
• Make sure the required roles exist and that the test accounts have actually been assigned those roles.
• Open destination pages in a regular and a private browser window to see their behavior before and after login.
• Keep a separate administrator account and a clear route back to the dashboard.
• Record the login and logout addresses before you begin editing, including their purpose for each group.
• While testing, clear or bypass login-page caching if it affects authentication and redirects.

The last item does not mean that every cache conflicts with the add-on. It means that authentication and the page shown afterward should be tested from a known browser state. An old session, a stored page, or aggressive caching can display an earlier page and falsely suggest that the rule was not applied. It is better to use a private window and log out of all test accounts than to change live settings based on an inaccurate observation.

Install the add-on and run the first safe test

The launch order matters: the main LoginPress plugin must work first, then the Login Redirects add-on is activated, and only then do routing settings become available. The official instructions show the path LoginPress - Add-Ons, where you enable the switch on the Login Redirects card. The documentation describes this module in the context of LoginPress Pro, so before planning your setup, check what is available in your own interface instead of relying on an item name from an old article or someone else's screenshot.

Do not activate the add-on and immediately create ten rules. First choose one test role and one simple published page. On a store site, a user with the Customer role and a properly functioning account page are suitable for the first pass. On a content site, create a test subscriber and a page called "Member Resources." The purpose of the first launch is to prove that the chain "role - rule - URL - opened page" works in your configuration, not to complete the entire route matrix at once.

What to check in the dashboard before adding the first rule

After activation, go to LoginPress - Settings and find the Login Redirects tab. If the tab is missing, do not try to create a rule through code at random. Return to Add-Ons, make sure the module is enabled, refresh the dashboard page, and check whether the site is in an environment with different accounts or restricted settings access. First get the add-on into a normal visible state, then start filling in fields.

Within the tab, do not begin with a personal user search if you need a broad use case. Open Specific Roles and review which roles the site actually returns in the search field. This is a useful audit point: you may discover roles created by a store, LMS, membership plugin, or an old customization. Do not assign a rule simply because a role name looks familiar. Match the role to a test account in the WordPress Users section. That prevents a situation in which a rule is saved for Subscriber while testing is performed as Customer.

Your first role route: a calm step-by-step process

1. Prepare a published destination page and open its permalink in a separate tab.
2. Create or select a test account that has only the required role.
3. In LoginPress - Settings - Login Redirects, open Specific Roles.
4. Find the role in the search field and fill in Login URL with the verified destination address.
5. If needed, specify a Logout URL, but do not confuse it with the post-login destination.
6. Click Update, then open a private window, sign in with the test account, and record the address that opens.

The word "verified" in step four is essential. Do not paste an example from the documentation into the field or use a shortened address if the site runs in a subdirectory, has a separate store domain, or was recently migrated. After saving, do not rely only on the dashboard notice. A real test always happens in a new session: sign in, inspect the address in the browser bar, open the page, confirm the correct content, and log out.

How to choose a logout destination

Logout URL answers a different user question: where should someone go when their session ends? For a customer, a public catalog or home page is often appropriate; for a course participant, a page describing the learning program; and for a private portal, a neutral public page with a clear login button. Do not send someone directly to a page that requires authentication after logout, or they will immediately return to the form and see a route that looks like an error.

You do not have to assign a logout address for every role. If standard WordPress behavior is clear and safe, an extra rule only makes maintenance more difficult. Add it where it makes the user's path noticeably clearer. Once the field is filled in, test the full sequence: "sign in - see the destination - sign out - see the public page," because testing login alone does not confirm the logout route.

Initial testing without misleading results

A good test is repeatable and does not depend on the browser's current cookie state. Use a private window, make sure it does not retain a previous login, and sign in as the test user. Then do not navigate manually to the destination page: evaluate the automatic routing itself. Record four observations: the account role, the form URL, the URL after login, and the visible content. Then log out through the site's normal link or provided element and record the URL after logout.

If a rule should work for several roles, test them separately. You cannot draw conclusions about customers from an editor account: different capabilities and site components can produce different behavior. In a store, it is useful to test a customer with an existing order and one without orders to make sure the account page opens in both cases. In an LMS, test a participant who has access to a course separately from one who does not: routing is responsible for reaching the entry point, while access is responsible for the correct content at that point.

Verify the outcome: after the first rule, confirm not only login and the address but also the ability to reverse the rule quickly. Record the path to the Login Redirects tab and keep access to it through a separate administrator session.

What to do if the first test does not match expectations

Do not add a second rule on top of the first. First return to the test-role row and verify that the intended URL was saved in Login URL, not in the logout field. Then check the user's role and the page's existence. If everything looks correct, temporarily remove the rule with Delete and repeat login. This rollback shows whether LoginPress Redirect Login changed the behavior or whether the issue exists without it. It is safer than disabling an entire collection of plugins at once and losing track of the cause.

After a successful test, move on to complete configuration. Transfer one rule at a time from the route map you prepared, beginning with the clearest broad role. Test the new route between additions. This builds not only a convenient login experience but also a record of decisions: at any time, it is clear which row controls a particular group and how to restore the previous behavior.

Detailed configuration for roles and individual users

Complete configuration begins not by filling in every field, but by deciding the scope of each rule. First create base routes by role, then add rare personal exceptions. This order keeps the dashboard readable and reduces the risk that a new user ends up in an obscure exception. For each row, record its purpose in a task comment, internal documentation, or route map: "Customer - account page," "Subscriber - library," "Editor - work instructions." Months later, that brief note will be more useful than trying to remember why a particular URL was entered.

Configure a role without hidden assumptions

Open Specific Roles, find the required role, and answer three questions before saving an address. Can the user see this page immediately after signing in? Do they need to land there after every login rather than only after following a particular link? What should happen after logout? These questions seem simple, but they separate an intentional route from an attempt to fix someone else's symptom. For example, if a customer should return to a cart, a permanent login route to the account page may be less convenient than the store's built-in behavior. If a subscriber always needs the resource library, a role-based route will be clear and stable.

After locating the role, enter the full verified address in Login URL. Do not add random campaign, debugging, or one-time session parameters. A permanent rule should contain a stable page that will survive content updates and changes of user. If the site uses different domains, protocols, or language directories, verify the final link especially carefully in the browser. The destination entered in the setting must match the address the user should actually open, not a similar address from a draft or editing panel.

Then define Logout URL or leave it empty if normal behavior is sufficient. When the field is filled in, it should lead to a public page appropriate for a user who has already signed out. A good logout destination makes the next action clear: browse the catalog, read about access, or return to the home page. A bad destination requires the same permissions that have just ended or hides the login form with no way to continue.

Saving is not the same as testing

After clicking Update, return to the row and make sure the intended address remains there. Only then proceed to test it in a new session. If you are changing several routes in a row, pause briefly between rules and test each one with a separate account. Otherwise, when something fails, it is difficult to tell which change caused it. On live sites, a short table with the change date, responsible staff member, role, destination, and test outcome can be useful. It does not replace a backup, but it can save hours when unexpected behavior needs to be investigated.

For a typical site, it is enough to begin with two or three roles. Do not try to prepare a route in advance for every technical role created by a third-party plugin. If a role never logs in through the normal form or has no distinct next task, it does not need its own rule. A minimal set of clear rules is usually more reliable than a long list that no one feels confident editing.

A personal rule as a managed exception

In the Specific User tab, find a user by name. The documentation shows that once selected, the row displays an ID, username, email address, and address fields. Verify these details before saving: similar names and test accounts are easy to confuse. Create a personal rule only when its purpose can be explained without saying "that is just how it has always been." For example, a partner-program manager may need to open a separate instruction page after login, while other authors use the normal editorial route.

Personal assignments should be reviewed regularly. A user may change responsibilities, be deleted, receive another role, or stop working with the site. Unlike a personal row, a role usually continues to reflect the access model. A personal rule is therefore suitable for a temporary exception or a unique task, but not for a broad use case. If you find ten similar exceptions, create a task to review roles rather than adding an eleventh exception.

When testing a personal rule, compare it with the role route. Sign in as the specific account and see what happens. Then sign in with another account that has the same role and verify the shared route. This paired test quickly shows whether the exceptional use case is separated from the broad one and whether it has affected people for whom the assignment was not intended.

Store rules: the URL should continue the customer's task

LoginPress documentation on WooCommerce compatibility suggests choosing the Customer role in Specific Roles and using the My Account page as the post-login address. This is a sensible baseline when a customer signs in to view orders, addresses, or profile information. Before applying it, however, verify what counts as the account area on your site: the store may use a renamed page, a separate login form, or additional tabs created by another extension.

Do not send every store user to the same page out of habit. A product editor, store manager, and customer perform different tasks and have different capabilities. The customer benefits from the public-facing account area. An internal role is more likely to need a tested dashboard workflow or a separate internal page if one genuinely exists. A redirect should not hide necessary tools from a staff member or force them through several pages after every login.

Also test the path from a protected page. Log out, open the account page as a guest, go to the login form, authenticate, and see which component chooses the final destination. If the store preserves cart context or the original task, that may matter more than a permanent route. Do not call every difference a conflict: first define which outcome helps the customer in the specific use case, then configure rules around that outcome.

Rules for learning and protected content

For LMS and membership sites, the most common mistake is sending everyone to one section without checking real access. A learner may have several courses, an instructor may have separate tools, and a new member may have only introductory material. If LifterLMS is active, LoginPress may display a special redirects section for courses and memberships. Here it is especially important to describe the rule in plain language first: which person, with which enrollment, after which login, should arrive at which starting point.

Do not create a route to a specific lesson if the user may not have access to it. A course catalog, personal learning area, or course hub is often a more stable destination because the system can display available items there. When you need a priority between multiple LifterLMS destinations, current LoginPress documentation describes a dedicated priority filter. That is a development tool for contested cases, not the first step in standard configuration. On a typical site, it is safer to test a simple route through the interface first and avoid adding code until there is a confirmed need.

Settings you should not enable "just in case"

Do not create a logout rule simply because the field exists. Do not create an individual assignment when it duplicates a role. Do not route an administrator to an arbitrary public page without a test confirming continued access to settings. And do not try to compensate for hidden login, forced login, a form widget, two-factor protection, and a store path all at the same time through redirects. Each component changes the user's path. Enable one important rule first, test it, and then add the next layer.

If a rule is temporary, set a review date in your own work system. A LoginPress row contains an address, but it does not explain the business reason. Without a note, a temporary route can easily remain on the site after a campaign ends, an account area changes, or roles are reorganized. Managed configuration means not only filling in fields correctly but also knowing when they need to be removed with Delete.

Quick takeaway: role settings form the foundation, while Specific User should be reserved for rare, justified exceptions. For every rule, verify the post-login address, post-logout address, access to the destination page, and the ability to roll back safely.

Build a route without conflicts from access, forms, or other plugins

You cannot build a convenient route with a single URL field when a site uses several systems. WordPress validates login and roles, LoginPress Redirect Login stores the assignment, a store or learning plugin creates the account area, cache serves the page, and the theme and menu give users links to continue. Each part has its own responsibility. The earlier you define those boundaries, the less likely a change in one place is to unexpectedly break another path.

In practice, that means the destination page must already exist and be ready to receive the user. It should have a clear heading, a next step, available resources, or profile data. Do not use a technical page without context as a destination simply because it opens. After login, a person should see confirmation that they have reached the right place rather than wondering whether the browser froze or the redirect sent them somewhere at random.

Assign responsibility before changing routes

Start with a short list of components. WordPress is responsible for accounts, roles, and basic authentication. LoginPress styles and extends the login page, while its Login Redirects add-on sets the target URL for a role or person. WooCommerce, an LMS, or a membership plugin is responsible for domain-specific data and access to its content. The theme displays links, menus, and the presentation layer. The caching system must handle session-dependent pages correctly. This division does not require a separate architecture diagram on the site, but it prevents the mistaken idea that "we can use a redirect to grant access."

For every use case, identify one primary entry point. If the header includes a link to the standard form, test that link. If the store uses a form on the account page, test that exact form. If an LMS provides its own screen, do not replace it with a test on another URL. According to LoginPress support guidance, LoginPress works with the standard WordPress login page; nonstandard forms and separate integration flows need their own testing. The more precisely you reproduce the visitor's real path, the more trustworthy the outcome.

What can affect the final destination

A typical site may have several redirect candidates: the redirect_to parameter in a link, a LoginPress rule, WooCommerce behavior, an LMS setting, an access restriction, a two-factor authentication plugin, and custom code through WordPress filters. They do not always conflict, but you cannot assume they will all run in the order you prefer. The same user may first complete a second factor, then receive a role route, and then be returned to the original protected page. Without testing, that chain can look random even though different components are acting in sequence.

LoginPress documentation specifically describes compatibility with WP 2FA: after the second factor is completed, the role route should run after authentication is confirmed. For a site owner, this leads to a practical rule: if a second factor is enabled, do not test LoginPress Redirect Login with only a password step. The test includes the login, the second-factor code, and observation of the final page. If a loop or the previous page appears instead of the destination, record all three addresses and temporarily compare the result with the rule disabled rather than changing several security systems at once.

Cache, browser state, and session behavior

A post-authentication redirect depends on an active user session. Pages that display personal data or login state should not look like a general copy saved for a guest. The exact cache configuration depends on the solution in use, so there is no need to invent a universal checkbox. A safe process is different: sign in in a private window, check the address and content, then repeat the test in a regular window after clearing cookies. If the behavior differs, review cache-exclusion rules for login and account pages in your caching solution's documentation.

Do not change the LoginPress URL, account-page URL, and cache settings at the same time. After every adjustment, repeat the same sequence. That turns troubleshooting from guesswork into comparison: before the change, a customer landed in the dashboard; after enabling the rule, they land in the account area; after adjusting cache, the account area displays current data. Observable steps matter more than a random collection of enabled switches.

A safe exception to the general route

LoginPress provides the documented prevent_loginpress_login_redirect filter, which can programmatically prevent a redirect for a specified user. It should not be used as a substitute for clear interface rules. It is appropriate when there is a justified exception that cannot be expressed through a role or user setting and when the site is maintained by someone who understands the consequences. The official example uses a condition based on a user ID and recommends placing changes in a child theme rather than a parent theme.

If you genuinely need this type of setup, it is safer to use a small snippet through a site-specific plugin or reliable custom-snippet tool and test it on a site copy first. The code below is an author adaptation of the documented filter: it keeps a user with a specific ID outside the LoginPress route. Do not copy the number from the example into a live site - first identify the correct account and decide why it needs standard behavior.

/**
 * Keeps the selected administrator outside LoginPress Redirects rules.
 * Replace 123 with the ID of the service account.
 */
function site_skip_loginpress_redirect_for_admin( $condition ) {
    global $user;

    if ( isset( $user->ID ) && (int) $user->ID === 123 ) {
        return true;
    }

    return $condition;
}
add_filter(
    'prevent_loginpress_login_redirect',
    'site_skip_loginpress_redirect_for_admin',
    10,
    1
);

The purpose of this snippet is not to create a "secret login," but to let a predefined service account avoid the general route when that is required for maintenance. After adding it, sign in as that account and as a regular test user. The first should keep standard behavior, while the second should receive the assigned destination. To roll back the change, disable the snippet or remove it from the child theme, then test both logins again. Do not add the snippet if an ordinary rule and a separate administrator session already solve the task.

Practical example: a customer returns to their account

Consider a full example for a WordPress store. The goal is to send a customer to their account page after successful login and return them to a public catalog page after logout. This setup is based on LoginPress documentation for WooCommerce: for the Customer role, assign the My Account page URL in Specific Roles. But correct configuration starts before you enter the rule itself: make sure the store actually uses that page as its account area and that the test user has the customer role.

Goal and test-case preparation

You need active WordPress, LoginPress, and a store; a published account page; and a test account with the Customer role. To verify account-page content, create a real test order in a staging environment or make sure the page correctly displays the state of a customer with no orders. Do not use an administrator instead of a customer: that does not prove the role rule works for the intended audience or that the public-facing account area is safe.

Before configuration, sign in as the test customer and record the current route. This is an important reference point. The site may already send the person to the account through WooCommerce, to the dashboard, or to a page defined by another system. You do not have to change a correct route merely because the add-on is available. The success condition is not "a setting has been created," but a clear, predictable path for the customer.

Configuration steps without unnecessary exceptions

1. Open the store account page and copy its actual permalink.
2. Go to LoginPress - Settings - Login Redirects.
3. In the Specific Roles tab, find the Customer role.
4. Paste the account-page address into Login URL and save the row with Update.
5. For logout, if needed, enter the public catalog address in Logout URL and save the change again.
6. Open a private window, sign in as the test customer through the actual login form, and check the account page.

In the final step, check more than the URL. The customer should see their own account area, not an access error, a cached blank page, or a dashboard link. Then sign out and verify the catalog address. If the store supports reaching the account from a protected area, repeat that path separately. This helps you avoid confusing a permanent LoginPress rule with a contextual return performed by the store itself.

A commonly missed detail

A post-login route does not replace access to orders. If a user reaches the account area but cannot see the required information, the issue is usually in profile data, the order, capabilities, or store settings, not in Login URL. For quick isolation, keep the destination address unchanged and open the account page directly under the same account. If direct access also shows incorrect content, investigate WooCommerce. If content is correct when opened directly but wrong only immediately after login, compare the destination URL, interference from other rules, and session state.

Outcome of the example: the customer signs in through a familiar form and lands where they can continue their task. Configuration is complete only after a new-session test, account-page verification, and logout-route test.

Verify the outcome: from the browser address to the real task

Testing LoginPress Redirect Login should answer the user's question, not only the administrator's. It is not enough to see the desired URL in settings or in the browser bar. You need to confirm that a person with the required role signs in through the real path, lands on the expected page, can perform the next action, logs out correctly, and does not lose access to the login form. This check takes only a few minutes, but it turns a rule from a technical attempt into a working setup.

Prepare separate test accounts for groups that should behave differently. Do not use one account with roles that are constantly being changed: after experiments, it is easy to forget its state, and plugins may retain additional profile data. It is better to have a simple subscriber, customer, editor, and backup administrator. Record the expected login and logout addresses for each one, then perform the same test set.

Basic verification procedure for each role

1. Open a new private window and make sure it has no active WordPress session.
2. Go to the actual login form visitors use, not a random administrative link.
3. Sign in with the test account and record the address that opens immediately after successful authentication.
4. Check the page heading, available areas, and the action the user signed in to perform.
5. Log out through the normal method available to the user and check the page after the session ends.
6. Repeat login through a header link, protected page, or integration form if that path exists on the site.

The final step often reveals an important difference. A simple permanent rule and a return to the original protected page can lead to different destinations. Do not try to decide in advance that one is universally correct. Look at the user's task. If a customer started checkout, returning to it may matter more. If a subscriber begins work in the library every time, a permanent destination page may be more convenient. In the test record, note the path leading to the form and the final outcome; otherwise, it will be unclear a week later why two tests produced different results.

Check access boundaries

After login on the destination page, verify not only what the user can see but also what they should not see. A customer should not receive site-editing items. A subscriber should not accidentally open an internal page with no understandable interface. An editor should not lose a necessary work area. A redirect does not create or remove WordPress capabilities, but it can make a role error more visible by taking someone directly to the page where that error appears.

For verification, open the site under two roles and compare not only the presentation but also the available action. For example, a customer in the account area can open an order but should not edit a post. An editor can open a work page and proceed to the required part of the dashboard. If two roles have the same destination, that can also be correct, but it should be intentional. There is no need to configure different URLs merely to make the roles appear different.

How to tell whether the logout address is a good choice

A good logout route leaves the user in a public area where it is clear what happened and how to continue. Check that protected data has disappeared, that the login button leads to a working form, and that another redirect chain does not start. If a catalog opens after logout, make sure it is accessible to guests. If it is an informational page, check that it does not contain links promising access without authentication. These details affect trust in the site more than the existence of the Logout URL field itself.

A separate test is needed if the logout link is in a LoginPress menu or store area. Different site elements may use different session-ending mechanisms. Do not replace working links merely to force identical behavior until you have proved that the difference creates friction for users. First make a list of logout paths, then test the most common ones. If the desired route fails on a specific button, record its source: the theme, menu, widget, or third-party plugin. That narrows the investigation.

What to record as configuration evidence

For important sites, create a short verification card. It only needs to include the test role, login type, expected URL, actual URL, post-logout page, verified action, and date of the internal check. Do not store passwords or other secrets in this card. Its value is that after updating the theme, store, LMS, or LoginPress, you can quickly repeat the same path and see exactly what changed.

If a team maintains the site, the card also helps explain a rule's purpose to a colleague. Instead of "do not touch this row," you have a clear description: "the customer role receives the account area after login because orders are available there; logout leads to the catalog; testing is performed with a test customer." This is good protection against accidental deletion and attempts to replace a setting with an untested code snippet.

Practical routes for different types of WordPress sites

The same feature works differently on different sites. The examples below are not ready-made recipes for mechanical copying, but a way to choose a destination based on the user's next task. In every case, first verify the role, destination page, and real login path. If even one element is not confirmed, keep the setting in a test environment until it is clarified.

Membership site: send users to the library, not an internal area

A subscriber usually arrives for content, not for the WordPress interface. For Login URL, choose the library start page, a collections page, or a clear "My Resources" section. Before saving, make sure this page is available specifically to an authenticated subscriber and points them toward the next action. If the site has several membership levels, do not send everyone to a section that promises higher-tier material. A neutral starting point where the access plugin already displays available content correctly is more reliable.

After logout, an access-information page or public catalog is appropriate. This destination does not force a person to sign in again immediately, but it leaves a clear way back. Test the setup in two states: for a subscriber with access and for a user whose access has ended. The route may be the same, but the visible outcome must match the rules of the access system.

Editorial team: reduce unnecessary clicks without bypassing roles

An editor's destination may be an internal guide, editorial calendar, or the regular WordPress dashboard. The choice depends on where the work actually begins. If an editor still needs to click several links after the internal page, it may be simpler to keep the standard dashboard. If the team has a shared task page with clear links to content, routing the role there is justified. Do not turn a URL into a permission-control mechanism: all capabilities must remain configured through WordPress roles and processes.

A useful check is to sign in as an editor, open the assigned page, perform one typical task, and return to the content list. Then sign in as an administrator and make sure the standard management path has not disappeared. If maintenance requires excluding an administrator from the shared route, first use a separate rule or backup session; apply the code filter only when there is a confirmed need.

Learning: use a course hub instead of a random lesson

A learner may be enrolled in several programs, so a personal learning page, course hub, or list of available courses is usually a stable destination. A specific lesson should be used only when it is genuinely the permanent required entry point and access is guaranteed. LoginPress documentation describes a LifterLMS integration and additional routes for courses and memberships. Use them only after verifying the installed integration and the learner's actual enrollments; do not copy LMS settings from someone else's example.

If several destinations overlap, do not hide the problem behind a random URL. First define the priority from the learning perspective: the main course, progress page, or catalog. The LifterLMS priority setting for developers is appropriate when simple rules are not enough and you can test it on a site copy. For most sites, a clear course hub provides a more predictable and maintainable outcome.

Quick takeaway: a good route is not measured by the number of rules. It is measured by whether a specific role can perform its next task immediately after login and whether the entire path remains clear after logout.

Troubleshooting routes: why users land in the wrong place

Redirect issues are easier to fix when you do not change settings blindly. Every failure has an observable symptom, a limited set of causes, and a short safe test. First reproduce the situation with the same role and the same login path. Then isolate the LoginPress Redirect Login rule: record the current values, temporarily remove only the relevant row with Delete, repeat the test, and compare the outcome. If the behavior does not change, the source is probably in another system. If it changes, restore the rule and inspect the role, URL, and overlaps with personal assignments.

The standard WordPress dashboard opens after login

Symptom: a customer or subscriber enters valid credentials successfully but lands on the standard WordPress screen even though another route was assigned. Possible cause: the add-on is not enabled, the rule was saved for another role, the address was not entered in Login URL, or the test was performed with the wrong account. Sometimes the user has multiple roles and the expectation is based on an untested match.

What to check: open LoginPress - Add-Ons and make sure Login Redirects is enabled. Then open Settings - Login Redirects, find the role row, and compare the address with the route map. In the WordPress Users section, check the actual role of the test account. Then repeat login in a new private window.

How to fix it: enable the module, correct the row for the required role, or create a rule for the correct test account. Save one change at a time. When to roll back: if adding the rule makes the standard route more predictable and useful for that login path, remove the row and first determine whether the store or LMS should remain the primary source of routing.

The address opens, but the user sees an access denial or blank page

Symptom: the URL after login matches the setting, but the page reports insufficient access, shows an empty personal area, or looks like a guest page. Possible cause: the LoginPress rule worked correctly, but the destination page was not designed for the role, requires data from another plugin, depends on course enrollment, or is being served incorrectly from cache.

What to check: open the same address manually under the same test account. If the outcome does not change, do not edit the redirect: investigate access, profile data, the order, course enrollment, or rules in the connected solution. If direct access works but the page fails immediately after login, compare the URL, session cookies, and interference from the form, store, or protection layer.

How to fix it: choose a stable starting page available to the required role, or configure access in the system that controls it. For a customer, this is usually the proper account area rather than an internal page; for a learner, it is a list of available programs rather than a lesson they are not yet enrolled in. When to roll back: remove the rule if the destination screen cannot be prepared safely and clearly for that role.

A loop occurs between the login form and a protected page

Symptom: after valid credentials are entered, the browser shows the form again, returns to the same page, or rapidly jumps between addresses. Possible cause: Login URL points to a page that sends a guest to login, but the session cannot be recognized in time. Other possibilities include an incorrect domain, inconsistent http/https, cached authentication pages, a protected-content rule conflict, or a hidden-login URL setting.

What to check: record the sequence of addresses instead of looking only at the final screen. Then temporarily remove only the LoginPress rule and repeat login. Check the destination page directly under an already authenticated user. Review permalink settings, the site domain, and cache exclusions for login and account pages. If Force Login, Hide Login, or another security mechanism is enabled, test it separately from the new route.

How to fix it: replace the destination with a published page available to the role after login, correct the address, and only then restore additional protection. When another solution conflicts, first determine which component must control access and which should merely choose the starting page. When to roll back: if the loop began after one specific rule, remove it with Delete, clear the test session, and return to configuration only after normal login has been restored.

The rule works for normal login but not through a store or LMS link

Symptom: a test on the standard form reaches the intended destination, but a user who opens a protected page or an integration form lands somewhere else after login. Possible cause: the path uses its own return parameter, account page, LMS handler, or another route that supplements the permanent role assignment. This is not necessarily a LoginPress error.

What to check: compare the full path: where the form was opened, whether redirect_to is present in the address, which form the visitor sees, and which URL appears after login. Repeat the test without the parameter and with it. For a store, also test the route to the account area and checkout; for learning, test course access and the second factor if it is enabled.

How to fix it: choose the expected behavior for each important path. Often, the permanent role route is retained for ordinary login while contextual return is preserved for a protected page. Do not force every link to behave identically if that makes the user's task worse. When to roll back: remove the permanent rule if it breaks a critical store or learning path and a more suitable mechanism already guides the user correctly back to the original task.

After enabling a second factor, the route runs too early or does not run

Symptom: the user enters a password but does not land where expected, or the path after confirming the second factor differs from ordinary login. Possible cause: the authentication flow has several stages, and another component participates in the final address selection. LoginPress publishes separate WP 2FA compatibility information, so this path cannot be treated as identical to a standard login.

What to check: create a test account with a second factor enabled and record three states: password submission, the code-entry screen, and the page after confirmation. Also check the same role without a second factor if site policy allows it in a test environment. Do not disable security on a live site merely to make testing easier.

How to fix it: update related components in a controlled order, verify role settings, and follow the documentation of the active two-factor authentication system. When to roll back: if adding the route disrupts mandatory second-factor authentication or creates a loop, first disable only the route for that role while preserving security and administrator access.

The logout address sends users back to login

Symptom: a user signs out but immediately returns to the form or to a protected page. Possible cause: Logout URL points to a destination that requires authentication, or the theme's logout link uses a different mechanism from the one that was tested. What to check: open the post-logout URL as a guest and make sure it is truly public. Then repeat logout through every prominent interface element.

How to fix it: replace the address with a guest-accessible catalog, home page, or access-description page. When to roll back: if standard WordPress logout already provides a clear outcome, clear Logout URL and do not create a special rule without a real benefit.

Core troubleshooting principle: first reproduce one route, then change one responsible layer. A rule that can be removed and restored in one row is safer to test step by step than to cover with new rules and untested code.

Questions about configuring LoginPress Redirect Login

Do I need to create a separate rule for every customer?

No, not if all customers should reach the same page. In that case, choose the Customer role in the Specific Roles tab and test it with a test account. Reserve personal entries in Specific User for rare exceptions where one person genuinely needs to open another page. Broad personal-rule collections are harder to maintain, especially after role and staffing changes.

Can a redirect protect a page from guests?

No. LoginPress Redirect Login chooses an address after successful authentication, but it does not manage role capabilities or turn a public URL into a protected one. Page protection must remain the responsibility of WordPress, the store, LMS, membership plugin, or another access component. Before making a protected section a destination, test it as a guest and under the required role. This lets you evaluate content protection and route behavior separately.

Why is an address assigned to a role, but the person still lands on another page?

First check whether the account actually has the intended role. Then investigate the real login path: a normal link, protected page, store form, and a flow with redirect_to may involve other mechanisms. Test the rule in a new private window and temporarily remove only that row. Comparing behavior with and without the rule will show whether the issue belongs to LoginPress or another system.

What should I use for Logout URL?

Choose a guest-accessible page that naturally completes the user's path. For a store, this is often the catalog or home page; for a membership site, an access-information page or public content showcase. Do not send a person to an account page, protected lesson, or another URL that immediately requires a new login. If standard WordPress logout already reaches a clear page, the field can remain empty.

Does the add-on work with WooCommerce?

LoginPress documentation describes a WooCommerce setup: select the Customer role in Specific Roles and use the My Account page as the post-login destination. On a real site, always verify the actual account page, login form, and the route from a protected area. Compatibility does not mean every installed store extension will automatically choose the same route, so test a customer in a new session with real account data.

What should I consider with LifterLMS and multiple courses?

If LifterLMS is installed and active, LoginPress may display additional route settings related to courses and memberships. For an ordinary setup, begin by choosing a clear learning start page available to the learner. Do not direct a user to a specific lesson until you have confirmed that enrollment and access are unambiguous. When several destinations overlap, first review the learner's path model, then consider the documented developer priority mechanism.

Do I need code to exclude an administrator from a route?

Usually not. Start with a separate administrator session, clear role rules, and a test account. The documented prevent_loginpress_login_redirect filter is useful only for a confirmed exception that cannot be expressed in settings. If you use it, place the small snippet in a child theme or site-specific plugin, test it on a site copy first, and know in advance how to disable the change.

Does LoginPress Redirect Login affect speed or search optimization?

The add-on works at login and logout, so its main responsibility is the route of an authenticated user, not public indexing. The real usability risk appears when cache or access rules return a guest copy of a personal page, create a loop, or send someone to an inappropriate screen. For the public site, it is more important to keep guest pages clear, avoid sending bots and visitors into meaningless loops, and test login paths separately from normal catalog browsing.

A focused video walkthrough of the add-on interface

For an initial look at the settings tab, an official LoginPress video about the Login Redirects add-on can be useful. It supports the same goal as the practical section above: assigning a post-login route for roles and managing settings in the dashboard. Watch it after reviewing the route map, so the interface actions are tied to your goal rather than becoming mechanical click-by-click repetition.

While watching, focus on three points: where the add-on is activated, how the Login Redirects area is opened, and how assignments for roles differ from those for individual users. Do not copy an example address literally afterward. Return to your destination table, enter only a verified page, and test it in a new session.

A regular review plan after updates and role changes

A route configuration should not remain unchecked after major site changes. Updating LoginPress, WooCommerce, an LMS, the theme, caching system, or two-factor protection can change one stage of the user path. You do not need to manually rewrite every rule after every update. It is enough to maintain a short procedure and a set of test roles that reproduce important use cases. This approach is especially valuable for stores and protected content, where a failure appears not for an administrator but for an ordinary visitor.

A minimal procedure for site owners

After changing plugins, sign in as a customer or subscriber in a private window and confirm the final page. Then log out and check the public destination. After changing roles or connecting a new tool, create a separate verification entry: which role was added, where it should lead, and which page confirms the outcome. After a domain migration, review all saved URLs because old addresses can remain in redirect rows unnoticed until the first user signs in.

If the site uses WP 2FA, test the route after completing the full second-factor flow. If the path from a protected page matters on the site, test it too, not only the form in the header. If caching is enabled, compare the result in private and regular windows. This procedure is short, but it covers the most common reasons for a false sense of safety: a rule appears to be saved, while a real visitor uses another path or sees an outdated page state.

Signs that the configuration should be simplified

Review the setup if similar rows have accumulated in Specific User, staff cannot explain the difference between routes, several components redirect the same role, or testing requires too many exceptions. A simple configuration does not mean one URL for everyone. It means every rule has a clear recipient, a real destination, a verified outcome, and an owner who knows how to remove it safely.

Reduce rules gradually. First record current behavior with test accounts. Then remove one duplicate personal rule, test the shared role route, and move to the next one only after success. Do not disable LoginPress, store settings, and custom code at the same time: that will make the outcome unclear and prolong recovery.

When LoginPress Redirect Login is the right choice

LoginPress Redirect Login is a good fit when a WordPress site needs clear routes after login and logout and the main routing behavior naturally follows a role or individual account. It is particularly useful for customers, subscribers, learners, and employees for whom the standard dashboard does not help them complete the next task. A strong configuration starts with a map of roles and destination pages, continues with one tested rule, and ends with a new-session test using the real content of the destination page.

Do not use redirects as a substitute for permissions, content protection, or complex dynamic return behavior. First identify the component responsible for access, make sure the address exists and is available to the required role, and check the effect of the store, LMS, cache, and second factor. If ordinary configuration is not enough, use the documented filter only as a small, testable exception, not as a way to hide disorder in the rules.

Once the route map is ready, a separate test account exists, and there is a clear rollback path, you can download LoginPress Redirect Login, enable the add-on, and begin with one role-based use case. After confirming the outcome, move the remaining rules gradually. This turns login from a technical barrier into a short, clear transition to the work users need to do on the site.