Choose the Login Identifier That Fits Your Website
A website may describe accounts in terms of email addresses while its login form still asks for a username or email. Another site may use recognizable member handles everywhere and want the sign-in experience to follow that convention. Login ID Type gives you an explicit choice instead of leaving the wording and accepted identifier to the default WordPress behavior. The setting applies as a website login policy, rather than a different rule you must define for every individual account.
Email Only rejects identifiers that are not email-shaped and asks the visitor for their email address. Username Only rejects email-shaped identifiers and asks for their username. Username or Email keeps WordPress's native choice and is selected by default. Returning to that mode removes this module's restriction hooks, so you can restore the standard behavior without changing user records or maintaining another set of authentication rules.
Change Authentication Behavior, Not Just the Label
Relabeling a field can make a form look consistent while leaving its actual authentication behavior unchanged. A form labeled Email address might still accept a username if nothing checks the submitted identifier. Login ID Type handles both sides of that problem. On supported login screens it changes the label, and in restricted modes it checks the identifier type before passing the credentials to WordPress's username or email authentication method.
That means the selected policy is enforced when the request reaches the server, not merely suggested in the interface. A user cannot choose the other identifier type simply by changing the browser's field label or sending a different value. The module still leaves password checking to WordPress's authentication methods. It selects which identifier is acceptable; it does not replace the password step or create a new account system.
Keep WordPress and WooCommerce Login Instructions Aligned
Customers and staff may encounter more than one login screen on the same website. A store can have WooCommerce My Account on the frontend and the standard WordPress login for administration. Login ID Type updates the supported labels and validates WooCommerce login errors as well as core authentication, helping those entry points follow the same identifier policy. An email-based storefront does not have to keep a contradictory Username or email address prompt simply because that is the default.
The module also works with Change Login URL, so moving the standard login screen to a custom address does not remove the identifier restriction. PowerSuite's 2FA AJAX login is covered too. These integrations support a consistent first step across the named workflows, while the custom login address and additional verification requirements remain the responsibilities of their own modules.
Give Clear Feedback Without Distinguishing Credential Failures
In a restricted mode, Login ID Type uses one instructional response for credential failures. Username-only login uses Use your username to log in. Email-only login uses Use your email address to log in. The response does not distinguish an unknown account from an incorrect password. This keeps the message focused on the chosen sign-in convention rather than announcing which part of a submitted credential pair was recognized.
Error ownership matters when Generic Login Errors is also active. In that situation, Login ID Type continues enforcing the identifier policy but leaves the generic sentence to the other module, and the settings display an overlap warning. For predictable instructional copy in a restricted mode, let Login ID Type own the message. For native username-or-email login with generic failure wording, keep the default mode and use Generic Login Errors for that separate purpose.
Define the Boundaries for API and Custom Login Forms
Not every authentication interface is a WordPress login screen. Login ID Type can also enforce the policy on REST and XML-RPC credential flows that use the relevant WordPress authenticate path, rather than treating its visible form labels as the entire feature. Supported PowerSuite 2FA AJAX requests follow the same first-step rule. This gives developers an authentication-level control for the covered requests instead of a restriction that exists only on wp-login.php.
Membership, learning-management, and custom login forms are not all rewritten automatically. They need to use the supported WordPress authentication path or opt in through the module's credential-login request filter. A custom interface may also need its own label updated so its instructions match the selected mode. Treat this as a defined integration boundary, not a promise that every third-party form or independent token-authentication system will be modified by one setting.
Keep Login Policy Separate From Account Changes
Choosing email-only login does not rename WordPress accounts, and choosing username-only login does not remove their email addresses. Login ID Type controls what a supported sign-in request accepts. Registration and password-reset identifier rules stay unchanged, so a recovery form can still follow its existing behavior even when the sign-in form uses a stricter policy. That separation prevents a login preference from silently rewriting the rest of the account lifecycle.
When the actual stored login name needs to change, Username Changer provides that different workflow. Use it for an intentional account rename, and use Login ID Type for the site's sign-in convention. This is especially useful when communicating a policy change: existing users need to know which identifier to enter, but you do not have to rebuild their accounts just to make the login screen consistently ask for an email address or username.
