Configure login and registration

Use Login & registration to customize the WordPress login screen, require authentication for site content, choose subscriber and registration destinations, and control native registration notifications. This guide is for site administrators.

Before you start

• Keep an authenticated administrator session open while checking access changes in a private browser window.
• Decide which individual behaviors you need. Enabling the module does not automatically enable its options.
• Registration must already be available in WordPress to use automatic login or a registration destination. This module does not enable registration or bypass multisite activation.
• Review compatibility with membership, approval, verification, security, and authentication plugins before enabling automatic login.

Enable and configure

1. Open Settings → POM Tweaks → White labelling → Login & registration.
2. Enable the Login & registration module and save if prompted to initialize it.
3. Select the individual options below. All are off by default.
4. Enter messages and select a registration destination where needed, then save the module.
5. Reopen the same tab and verify the saved selections, then check the affected public flows.

White labelling → Admin appearance remains the place for login logos, colors, spacing, and other visual styling. Login and registration behavior is configured separately and applies to the current site, not the network administration screen.

Login screen options

Keep error wording neutral so it does not reveal whether a username or email exists. The form message accepts safe HTML; scripts and unsafe markup are removed on output. Instructions shown here are public and must not contain private information. Existing WordPress notices, including logout and recovery instructions, take precedence over the custom form message.

Access and redirects

Require login to view the site redirects signed-out visitors to the native login page while preserving the requested destination. Anonymous REST requests receive an authentication error instead of HTML. Existing REST authentication errors are preserved, and authenticated requests remain available.

Login and password recovery remain reachable. Scheduled tasks and WordPress AJAX handling are not redirected by this module. Directly served files, page-cache responses, and plugin-specific public endpoints need their own access controls; this option does not make an entire hosting account private. Exclude restricted content from public full-page caches.

Redirect subscribers to the home page after login applies only to users whose sole role is Subscriber. Administrators, users with additional roles, and failed logins retain their original destination. This is a login redirect, not a prohibition on subsequently visiting an administration URL.

Registration and notifications

Automatic login respects rejection through the WordPress user-authentication filter. Verify any additional approval, verification, or two-factor flow supplied by other plugins before relying on this option. It does not choose a new post-registration destination.

Enable Redirect users after registration and select Registration destination page in this same module. The page selector lists published pages without password protection; select Keep the WordPress destination to leave the default destination in place. A deleted, unpublished, password-protected, or invalid destination also leaves the existing WordPress destination unchanged. This option uses the native registration form's redirect field and does not redirect ordinary logins, failed registrations, password recovery, or administrator-created accounts.

Choose a page accessible to a newly registered visitor. Registration redirection and automatic login are independent: without automatic login, the visitor may still be signed out. If Require login to view the site is enabled, the selected page requires authentication too. Multisite signup and activation use their own workflow and are unaffected.

Verify the result

1. Open the login page signed out. Inspect the logo link, accessible text, message, and keyboard navigation.
2. Try an invalid username and an invalid password. Confirm the chosen error wording and animation behavior.
3. Open password recovery and registration. Confirm that useful validation instructions remain visible.
4. Sign in as a subscriber and as an administrator; compare their destinations.
5. With login required, request a public page and an anonymous REST endpoint. Confirm the login redirect and REST error, then repeat with authentication.
6. Where single-site native registration is enabled, open a fresh registration form, create a disposable account, and confirm the selected destination, session, and email behavior. Check administrator-created accounts separately.
7. Disable only Redirect users after registration and repeat from a fresh form to confirm the normal destination. On staging, also verify that unpublishing the selected page restores the default destination.
8. Reset a disposable user's password and confirm that only the intended administrator notification is suppressed.

Troubleshooting and disabling

• An option has no effect: check both the module enable switch and the individual option, save, and reopen the same site's tab.
• The custom form message is missing: a WordPress informational notice takes priority. Also check its individual switch and content.
• Automatic login does not occur: check that this is native single-site self-registration, not multisite activation, an import, an administrator action, or a custom registration endpoint. An authentication plugin may reject automatic sign-in.
• Registration keeps its default destination: check the individual redirect switch and select a published page without password protection. Reopen the form after changing the settings. Multisite signup and plugin-specific registration flows are separate.
• A subscriber keeps another destination: check for additional roles and other redirect filters.
• A public page remains visible: check full-page caches and direct files, which may be served before WordPress can enforce authentication.
• Access rules cause problems: use the administrator session kept open to disable Require login to view the site, or disable the whole module.

Disabling an individual behavior stops its contribution on the next request. Disabling the module stops all its hooks while retaining the saved configuration. Existing login sessions, delivered emails, and created accounts are not reversed.

Related guides

• Customize WordPress administration appearance
• Customize the login and registration journey