We’ve recently been working on a problem where the user ends up on a White Screen Of Death (WSOD) when the WordPress login form was supposed to have been processing the request.
It happens in the following situations.
- User visits a page where the login form’s HTML is similar to that shown below.
Note: The values of
- The “humancheck” cookie does not exist.
HTML for the inline login form
The HTML generated by the standard WordPress login api ( wp_login_form ) is as follows.
<form name="loginform" id="loginform" action="http://bobbingwidetechsupport.com/wp-login.php" method="post">
<input name="log" id="user_login" class="input" value="" size="20" type="text">
<input name="pwd" id="user_pass" class="input" value="" size="20" type="password">
<p class="login-remember"><label><input name="rememberme" id="rememberme" value="forever" type="checkbox"> Remember Me</label></p>
<input name="wp-submit" id="wp-submit" class="button-primary" value="Log In" type="submit">
<input name="redirect_to" value="http://bobbingwidetechsupport.com/2014/08/12/problems-human-check-wp-login-php/" type="hidden">
Login form looks like this
If you’re not logged in then the login form should be displayed.
- For sites with wp-members it’s possible to use the standard WP-members solution to block the post/page. The input from the WP-members form does not get submitted to
wp-login.phpso it works without being intercepted by the Human Check.
- Ask the hosting company to remove the cookie logic for this site.
- The WP-members blocking method doesn’t appear to work on parent pages… which is one reason why we were using [bw_login] – as belt and braces.
- The problem occurs even if you attempt to ensure that naked domains are redirected to the www version. e.g. bobbingwidetechsupport.com gets redirected to www.bobbingwidetechsupport.com
- Ask the hosting company to alter the cookie logic so that the “Are you human?” page does appear to this legitimate user.