The Front End Login module lets you put a login form anywhere on your WordPress site, freeing you from the constraints of WordPress’ built-in login page. Use this module to create a login page that works with your organization’s branding and provides users with additional information or support. You can even place it side-by-side with a registration form to have a combined login + registration page, reducing the steps necessary for new users to create an account on your site.
The Front End Login module includes extensive customization options in its settings pane. Most are self-explanatory and won’t be covered here, but these are the most important options:
- Enable AJAX: Add AJAX form submission; this must be turned on to use the modal login shortcode and menu item.
- Select Template: Choose the design template for the login form. The “Boxed with shadow” template is required if you plan to use modal login forms.
- Login Page: Select the page you want to use as the login page for your site. This page must have the Front End Login Gutenberg block or uo_login_ui shortcode on it. When users attempt to access the default WordPress login page (/wp-login.php), they will automatically be redirected to this page instead.
- Manual User Verification: If enabled, users that register from the front end MUST be manually approved by an administrator before they can sign in. A “Verified” column will be added to the list of users in WordPress and any users listed as “Not Verified” cannot sign in. To verify a user, navigate to the user’s profile and look for the “Verify User” label. By selecting this field and saving the page, the users will be able to sign in. On verification, users will also be notified by email that the account has been verified and access has been granted. The Login Page setting (above) must set for user verification to work.
- Login Form: Use the fields in this section to customize the appearance and behavior of the main login form.
- Show Register Link: If enabled, a text link will appear below the form using the text in the Register Link Text field and linking to the URL in the Register Link field. This link can be to any page you want; even an external CRM (for example).
- Hide All For Logged In Users: If enabled, logged in users will see nothing where the login form was previously displayed.
- Message For Logged In Users: This content is displayed to logged in users (as long as Hide All For Logged In Users is not enabled).
- Modal login: Choose the button label for the modal login shortcode and whether or not to dim the background when the modal is displayed.
- Google reCAPTCHA Settings: When the Site Key and Secret Key fields are populated with valid reCAPTCHA v2 keys, a reCAPTCHA anti-bot widget will be displayed on the Login and Forgot Password forms. Users will be required to validate that they are not bots to enable form submission.
- Forgot Password Form: Use the fields in this section to customize the appearance and behavior of the forgot password form.
- Forgot Password Email: Use the fields in this section to customize the email that’s sent to users when they request a password reset.
- Reset Password Form: Use the fields in this section to customize the appearance and behavior of the reset password form.
- Require strong password: When this box is checked, users will be required to enter a password containing a minimum of 8 characters including 1 uppercase character, 1 lowercase character and 1 number.
- Two-Factor authentication: This section indicates whether two-factor authentication has been enabled via the WP 2FA plugin. When the WP 2FA plugin is installed and activated, the Front End Login module of the Uncanny Toolkit supports two-factor authentication for any users that have enabled it. You can also enable it sitewide for all users. Refer to the WP 2FA plugin documentation for setup details. Note: Uncanny Owl is not affiliated with WP 2FA or WPWhiteSecurity.com.
Important: Make sure that your login page is not cached. If you see password reset errors, redirect errors or users can’t sign in properly, check this first. Your host may also have server-side caching enabled for your login page (WP Engine and Siteground are known to do this, as are many others), so check with them if you’re not sure.
Also make sure that you are NOT using a separate reCaptcha plugin that also modifies login forms; it will create a conflict and you may be locked out. To include reCaptcha in the login form you must use the option included in the module.
The Front End Login module includes three shortcodes.
This shortcode displays the Front End Login form with the template and options selected in the Front End Login module settings.
This shortcode displays a barebones login form for use on secondary pages (i.e. pages not set as the login page). We recommend using the uo_login_ui shortcode for most use cases.
This shortcode displays a link (that can be styled with CSS if a button is preferred) that launches the login form in a modal window. The shortcode will only work if AJAX is enabled for the form and it requires the use of the “Boxed with shadow” template.
The shortcode supports a redirect attribute:
This is useful if you want to have different login pages that will redirect users to different pages. Any redirect set in the shortcode attribute will override the redirect set in the login redirect module.
The redirect_to parameter
Version 3.2 of the Toolkit introduced support for the redirect_to parameter, so that when “?redirect_to=%URL%” is appended to the URL of a login page (where %URL% is the target URL), users are directed to that page after logging in. This feature allows site admins to direct all users to a single login page but set different redirect behaviours based on how they arrived on that page. The the redirect_to parameter overrides both the redirect shortcode attribute and the Log In/Log Out Redirect module, so it will take priority.
An example of this module in use might look like this: “https://www.uncannyowl.com/login?redirect_to=https://www.uncannyowl.com/learner-dashboard”. The /login/ page in this example would have to include the uo_login or uo_login_ui shortcode.
Overriding the login templates
As of Uncanny LearnDash Toolkit version 3.1, developers can edit template files in an upgrade-safe way using overrides. Copy the template file into a directory within your theme named /uncanny-toolkit/, keeping the same file and folder structure but removing the /templates/ subdirectory.
For example, to override the default login form, copy:
The copied file will now override the default.
Warning: Do not edit these files within the the Uncanny Toolkit plugin itself, as they are overwritten during the upgrade process and any customizations will be lost.
The modal login form can pop up on any page based on selection of a menu entry, but it requires that the Log In/Log Out Links module be turned on. Once it is, a “Front end login modal” menu option will be available under Uncanny Menu Links on Appearance > Menus. Note: The link will not display the modal login form on the page set as the Login Page in the module settings. Instead, it will simply reload the page. This is to avoid complications from having two login forms on the same page.
If You Lock Yourself Out
If invalid settings have been made and saved, then after logout with invalid settings you find yourself locked out, take these steps immediately so that you can sign back in:
- Connect to your site by FTP.
- Find the folder for the Toolkit plugin in the plugins folder under /wp-content/.
- Rename the Toolkit folder temporarily to disable it.
- Log in now as an admin from the default WordPress login page.
- Change the folder name back by FTP and activate the Toolkit while you’re still signed in.
- Correct any settings from the Modules page and test the login page again in an incognito window or another browser so that you don’t accidentally lock yourself out again.
This type of scenario is possible if you turn on a maintenance mode or sitewide protection plugin that blocks access to the page set as your login page. If you do use a plugin that redirects access on a sitewide basis, make sure you exclude your login page from the redirect behaviour.