This question/answer covers a number of elements. If you are having issues with users being able to log in (including admins and/or test user registrations), it is most likely covered by one of the following. Please make sure you understand what settings you have enabled for the plugin as issues with log in that are not “user error” (i.e. wrong passwords) are most often related to not knowing/understanding how you have actually set up the plugin.
The login function works
If your initial thought is that there is something wrong with the login function itself, that’s not likely the case. The WP-Members login process uses WP’s wp_signon() to authenticate users, so the actual login isn’t from the plugin; it’s a core part of WordPress and it’s not broken.
Is the plugin set to require user confirmation?
If this setting is enabled (WP-Members > Options > Confirmation link), then the user must be confirmed before being able to log in.
When enabled, a user will not be able to log in until they have confirmed their account by clicking the confirmation link in the email that is sent to them.
IMPORTANT: If you enable this setting on a site with existing users, none of those users are confirmed. They will not be able to log in until they are marked as confirmed.
You can manually confirm a user in the Users > All Users screen with the “confirm” hover link under the user’s username. There is also a utility code snippet you can use to set all existing users as confirmed.
NOTE: This should not be confused with moderated registration (which is discussed below). The confirmation setting is the process of a user “self confirming” their account via a link sent to them in an email. Moderated registration is the process of requiring an account to be approved by an admin prior to being active.
Is moderated registration enabled?
If you have enabled moderated registration, all users must be set as activated before they can log in. That means ALL users – admins, too.
The ONLY user the plugin assumes should be automatically activated is the user who enabled the moderated registration setting. That is done by default to make sure you don’t lock yourself out of the site. But all other users must be activated.
When creating a new user manually through the Users > Add New screen, you can set a user as activated when creating them.
If you are testing and the login fails, if you have moderated registration enabled, make sure that the user is activated.
If you are setting up WP-Members on a site with existing users AND you are enabling moderated registration, you may wish to set existing users as activated. There is a utility code snippet you can use to set all existing users as activated.
User activation can change passwords
If you have moderated registration enabled AND the plugin sends the user an initial randomly generated password (i.e. the users do not create a password at registration), then the password is set when the user is activated.
This is an important thing to understand when working with a site with existing users, importing users, or manually creating users because if the user password is set when they are activated, you may think the password is one thing, but it is actually something else.
- If there is no password field included as part of the registration form, a random password is emailed when the user is activated. Any other password will be invalid.
- If there is a password field included as part of the registration form, the password is the password set at registration.
wp_signon() triggers core WP actions
If you have added a plugin that integrates additional validation into the WP login, the WP-Members login will be affected, too. Certain plugins add captchas or additional validation to the login form, which means that the authentication process in WP will be validating for that additional information. WP-Members includes core WP hooks in the login form so that added fields can be included. However, not every plugin is built in a way that can accommodate this.
There are plugins that add to the wp-login.php, yet only include their scripts in wp-login.php. That renders them incompatible with not only WP-Members, but any other plugin with a front end login that uses wp_signon() (which is quite common in membership sites, ecommerce sites, and other elements like forums and event management). Unfortunately, there isn’t a way to integrate with other plugins that make development decisions without regard for broad integration.
If you have a captcha on your wp-login.php that doesn’t show in the WP-Members login form, then this is most likely your issue. Track down the plugin that adds that captcha, disable it, and re-test.
Overly aggressive or improperly configured cache
The last common issue is difficult to diagnose. If none of the above are the issue and you are absolutely 100% certain that the password is correct, it is possible you have a cache that is improperly configured or is simply so aggressive that it serves the login form (cached) even if the user is logged in.
Check to see if your hosting setup uses a server-side cache called “Varnish”. Check with your host to see if Varnish is installed on your server. If it is, this is the issue. Varnish can be a great cache tool. However, it can be an issue with WP-Members because of the way WP-Members filters the content. Varnish wants to serve the cached page, which will be the non-logged in version. You’ll need to create a dedicated login page, and then have an exception for that page in Varnish.