Offer WordPress Passwordless Login Without Replacing Accounts
For a user who visits occasionally, entering an account password can be the point where an otherwise simple task stops. Magic Login offers another route: enter the account email address, receive a short-lived sign-in message, and complete access through the link or enabled code option. The user still signs into a WordPress account with its existing permissions. The module changes how that authentication begins rather than creating an anonymous session or granting a new role simply because someone requests an email.
This is a different workflow from administrator-issued support access. Temporary Login is for an administrator creating and controlling an invitation, whereas Magic Login is a self-service email sign-in option for eligible users. That distinction helps avoid using a reusable support invitation as a general customer login method. Magic Login's request response also avoids confirming whether an email belongs to an account, so the public form does not deliberately reveal account existence through its success message.
Use a Link, QR Code or One-Time Login Code
Keep Links Short-Lived and Request Volumes Controlled
A login link should have a clear lifetime rather than sitting in an inbox as permanent access. Magic Login defaults to a 15-minute expiry, with configurable values from 5 to 60 minutes. A new request invalidates the previous unused link for that user, so there is only one live unused link at a time. This keeps the request history from becoming a collection of simultaneously valid credentials and explains why an older email may stop working after another one is requested.
The module also limits requests by both IP address and email address. Default request limits are five per IP over five minutes and three per email over two minutes, with separate controls for repeated code guesses. A honeypot is enabled by default as another check on the request form. These measures govern the Magic Login workflow itself; they are not a claim that the entire website is protected from automated traffic or that live login emails no longer need careful handling.
Place Passwordless Sign-In Where Your Users Need It
Magic Login can appear as an additional option on wp-login.php, on its dedicated full-screen route, or inside your own content using [wp_powersuite_magic_login]. The shortcode provides a way to place the email request form in a branded page rather than forcing every visitor through the default WordPress screen. Its presentation has a starting card and button style, with optional custom CSS for projects that need a closer visual match to an existing layout.
WooCommerce login placement is optional and starts disabled, while the standard WordPress login option starts enabled. These separate choices allow you to introduce passwordless access where it is useful without automatically adding it to every account surface. For the destination after success, Redirect After Login can supply the configured policy. When that module has no applicable rules, Magic Login uses its own fallback behavior, including WooCommerce My Account when WooCommerce is active. Placement and post-login navigation therefore remain separate, deliberate parts of the experience.
Control Who Can Request Access and Whether Registration Is Open
The allowed-roles setting can restrict Magic Login to the account groups that should use email-based sign-in. Leaving that list empty means no role filter, rather than disabling the feature. This is useful when a website wants passwordless access for selected members or customers but intends other accounts to follow a different authentication policy. Requests still pass through the module's email checks, request limits, and any configured CAPTCHA protection before the corresponding access workflow proceeds.
Registration is a separate option and is off by default. When enabled, an email address that does not belong to an existing account can receive a complete-registration link, with Subscriber as the default new-user role. The shortcode's automatic mode can distinguish an existing-user login from the permitted registration invitation. Enabling Magic Login alone should therefore not be described as opening public account creation: the registration setting and selected role remain intentional administrative decisions within the passwordless workflow.
Retain 2FA and Add CAPTCHA Through Magic Login's Own Controls
A passwordless first step does not have to remove a site's additional verification requirement. Magic Login can hand applicable accounts to Two-Factor Authentication before access is completed. Its 2FA-bypass option is off by default, so bypassing that challenge is a separate setting rather than an automatic consequence of using an emailed link. This matters on sites that want convenient primary authentication while retaining the second-step policy already assigned to selected roles.
Magic Login also has its own CAPTCHA selection: none, Google reCAPTCHA, or Cloudflare Turnstile. Those integrations use the shared PowerSuite verifiers for the Magic Login action. They should be configured through this workflow rather than assuming an ordinary login-page CAPTCHA toggle automatically protects the magic-link request form. Together with the honeypot and request limits, the options let you decide how much verification the request stage needs without confusing CAPTCHA with account authentication or 2FA.
Add Login Access to Eligible Emails and Review Activity
Some websites already send account-related emails and may prefer to include a sign-in action in that communication. The optional auto-login placeholder feature replaces {{MAGIC_LINK}}, {{MAGIC_LINK_BUTTON}}, or {{MAGIC_LOGIN_QR}} inside an eligible WordPress email body for its recipient. It starts disabled and still respects the recipient's eligibility and request limits. This is not permission to insert live credentials into every outgoing message; enable it for a deliberate email workflow and treat the resulting access link as sensitive account information.
The dedicated Magic Login page includes an activity list, and an optional Users-table statistics column provides another place to review usage. Successful authentication also exposes an event that Admin Login Alerts can use for qualifying administrator notifications when configured. These tools provide operational visibility, but successful email sending should not be confused with guaranteed inbox delivery or a completed login. Test the actual email and verification flow so the sign-in option works for the people who are expected to rely on it.
