Domain Mapping v4.4.0.5, WordPress 4.2.2 in subdir mode with wp-{login,admin} forced SSL.
Somewhere between DM v4.4.0.3 (which worked okay) and v4.4.0.5, we’ve been having trouble with logins to subsites in a WPMS installation:
1. An admin user, with no cookies whatever (eg from a private browsing session) goes to
https://original.com/siteslug/wp-admin/
2. Since no cookies, the browser gets a 302 to:
https://original.com/siteslug/wp-login.php?redirect_to=https%3A%2F%2Foriginal.com%2Fsiteslug%2Fwp-admin%2F&reauth=1
NB: See very end of this post for a clue that might be relevant to diagnosis
3. User logs in but, instead of going to siteslug’s wp-admin, the browser gets a 302 to
https://original.com/siteslug/siteslug/wp-login.php
(Note the duplicated /siteslug/ component of the URL.) The user is still not logged in and cannot access their dashboard because the 302 didn’t return auth cookies.
Pretty much the same thing happens without the ?redirect_to etc.
Note that an attempt to access the root site’s dashboard directly (eg https://original.com/wp-admin/) redirects and logs in as you would expect. So the problem appears to be the presence of the site slug.
Work around, therefore:
1. Go directly to https://original.com/wp-login.php
2. Log in
3. Then go to https://original.com/siteslug/wp-admin/
Even though the POST to wp-login.php returns a 302, it does also return Set-Cookie headers, so everything will work as expected.
It’s an annoying bug (mainly because I keep getting support requests about why my admins can’t log into their sites), but the work around makes it not a critical one.
First sign of something going wrong:
Look at the HTML for the login screen at stage #2 (of the failure case). Though every other URL in the mark-up is of the correct form (domain.com/siteslug/whatever), the action URL of the login form itself is already wrong, ie:
<form name="loginform" id="loginform" action="http://original.com/siteslug/siteslug/wp-login.php" method="post">
Unfortunately, that can’t be the only problem because if I edit out the extra siteslug in the HTML directly in my browser, the result is the same.
If I take the siteslug altogether, it fails once again but, this time, the form URL is correct and an attempt to log in works per the work-around.
I don’t know how much help that is, but maybe it’s a clue as to where to begin to look.
If you can point me at a copy of v4.4.0.4, I’ll try that and see if the problem was introduced in 4.4.0.4 or 4.4.0.5.