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 ofaction=site_url/wp-login.php
andmethod=post
. - 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.
[bw_geshi html]
[/bw_geshi]
Login form looks like this
If you’re not logged in then the login form should be displayed.
Problem workaround
- 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.php
so it works without being intercepted by the Human Check. - Ask the hosting company to remove the cookie logic for this site.
Notes
- The WP-members blocking method doesn’t appear to work on parent pages… which is one reason why we were using [bw_code 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
Problem resolution
- Ask the hosting company to alter the cookie logic so that the “Are you human?” page does appear to this legitimate user.