Though I do the majority of my work using single site WordPress installs, there are a number of sites and projects in which I’ve used WordPress multisite and there’s a problem that I’ve experienced specifically with using WordPress multisite, subdomains, and shared hosting environments.
Specifically, the problem is this:
- Install WordPress and activate multisite
- Configure the installation to use subdomains (versus subdirectories)
- Attempt to login and get stuck in a redirect loop
If you have a single instance of WordPress multisite installed on the same server, there’s no issue, but if you go beyond that then you normally hit a problem: a redirect loop.
The WordPress Multisite Redirect Loop
The most frustrating screen ever (in a redirect loop, that is).
Once you’ve increased the number of your multisite installs beyond one, then you’re likely to be unable to login as you’ll get stuck in a redirect loop. That is, every time you try to login, you’re returned to the login screen.
Luckily, the fix is relatively easy.
In your wp-config.php file, add the following lines of code:
define('ADMIN_COOKIE_PATH', '/');
define('COOKIE_DOMAIN', '');
define('COOKIEPATH', '');
define('SITECOOKIEPATH', '');
And do so just before the line that reads:
/* That's all, stop editing! Happy blogging. */
Once done, the redirect issue should be resolved.
Why Does This Happen?
Whenever you’re running multiple versions of WordPress on the same server, you can visualize the setup like this:
WordPress Multisite Installation
Basically, each version of WordPress, regardless of its domain or subdomain, maps to a single IP address. In this case, 192.168.0.1.
When a request comes into the server, part of the request includes the domain. A domain is associated with an IP address. When a cookie is created, it includes the name, some sensitive content, and then the path.
For example:
NAME = wordpress_d676ec21cf050e966685794aa715694f CONTENT = removed PATH = /sitename/wp-admin
In a WordPress Multisite setup a cookie for two sites may look like this:
NAME = wordpress_d676ec21cf050e966685794aa715694f PATH = /sitename/wp-admin NAME = wordpress_d676ec21cf050e966685794aa715694f PATH = /sitename/
Notice that the name of the two cookies above are exactly the same but the path’s are different. This is because two different sites with different domains are hosted on the same IP address, and they both exist in the cookie because the cookies aren’t being reset.
Cookies being set for the different sites on the same domain.
As such, when you attempt to login to a WordPress installation on a different domain (but on the same IP), the cookie is essentially invalid.
Thus, WordPress – in the most technical term possible – wigs out.
But more seriously, wp-login doesn’t attempt to look for cookies before actually setting them. This means that an invalid cookie is being used and since it doesn’t attempt to clear the existing cookies, you get stuck in the login loop.
Thus, the big picture looks something like this:
WordPress Multisite and Cookies
Sure, clearing the cookies will do the trick, but users shouldn’t have to do that. Additionally, not everyone will see this problem occur, but if you’re in the business of managing a multisite installation in a shared environment, then you’re likely to see it.
The code above will ensure that WordPress is clearing the cookie for the given domain of the multisite thus allowing the login process to set it correctly.
This snippet of code worked like a dream, so thank you. Odd that I had the problem a day after you posted the solution too.
That’s awesome – what a coincidence
Thanks so much for posting this, I’m anxious to try it on an issue I’ve been having after a Multisite migration attempt. I’ve migrated a Multisite install to another domain for dev-ing and am getting this redirect.
Hopefully this will solve the issue for me:)
Sure thing – if it doesn’t work, let me know. This particular issue is one that obviously hits close to home so being able to provide as many solutions to it as possible would be great.
Worked like a charm! I was banging my head against my keyboard trying to figure out what was making it loop. And, oddly, I just installed with just one site.
This could be a problem depending on the hosting configuration, but who knows. There’s so many different providers these days.
Either way, that’s awesome – glad it helped!
I had similar problem with a sub-directory WPMS setup. mine would come up with a browser error of too many redirects. I had already tried clearing cookies and cache.
This fix solved it! Thank you!
Awesome – glad to hear it!
I also had a cookie problem on a subdirectory install of multisite. One point to mention and i’m not sure why this occurred but WP didn’t like this line:
define(‘COOKIE_DOMAIN’, ”);
Once i removed that line from wp-config.php it seemed to still fix the problem.
Any thoughts?
Personally, no. I’ve been using the subdomain multisite setup and the above solution is what has worked for me.
THANKS A LOT you solved my 1hr-headache.
Peace and love to you and your family.
Sure thing, ashorlivs.
Appreciate that
I also have a loop in wp-admin section. I’ve added your code, but it still have no effect: the login redirect loop is here.
This could be a result of a number of things. The post is specifically targeting a common problem that I’ve seen with multisite.
Unfortunately, I can’t offer much more than what’s above, but if you happen to come to a resolution, feel free to share it here for future readers.
Same issue as Stas…it was a good try – thanks for pointing it out – but the redirect loop persists.
Sorry it couldn’t be more help!
Thanks that really helped! I don’t really follow why this is a problem on local and not on a live server, which will also have the same IP for each site?
Secondly, as I’d like to maintain one set of code that works on live and local, can the 4 paths exist in the LIVE config file, or will this break logins there?
That is odd as I normally see it the other way around
. I was going to double-check about the IP issue on the server, but if it’s not a problem there then it may simply be a result of the routing mechanism setup on the server (unless you’re on a run-of-the-mill host).
The most critical paths are in the database, so if you have different paths for your
siteurlandhomevalues in thewp_optionstable, then you’re out of luck. =TGreetngs Tom, and thanks for all the information which has been provided above.
We have applied the changes above, but it has yet not resolved our error. For we have a setup such that blog.domain1.com and blog.domain2.com. The login for blog.domain1.com works correctly, but the login for blog.domain2.com gives an error.
We have tested, the configuration for both the blogs from the admin console, we have tested all the php files which are the same except for a few obvious changes.
Any inputs or pointers will be appreciated.
Hey Saurab,
Unfortunately, there may not be much more can I offer. What error does the login for
blog.domain2.comgive? Make sure that that user has been granted permission in the main multisite admin panel – sometimes that can cause an error.Hi, I should have stated it more correclty. My mistake. The login on blog.domain2.com does not give an error but redirects to the /wp-login.php without any error as such. No message on the screen. Just verified that the user has been added to blog.domain2.com and has adequate permissions.
One more funny thing which I observed, is if i go to the main blog and navigate to my list of blogs, and click on the blog, it opens the blog blog.domain2.com for me. Then I type /wp-admin at the end as in blog.domain2.com/wp-admin and press enter. I am taken to the dashboard.
Thanks and appreciate any help you can give me. Frankly can use any help I get.
Unfortunately, this sounds like more complicated of a problem that I can provide via blog comments, but I’d double-check your
.htaccessfile, yourwp-config.phpfile, clear your cookies, and disable any caching plugins if you have them.I’d also recommend trying to login with another browser and see if the problem persists there, too. If it does, then the problem definitely exists on the server so that’s the next place I’d start looking.
Thanks so much. I’ve spent days looking for this problem. You fixed it
Love it – that’s what it’s here for
.
A BIG thank you to you!!! wordpress.org forums have 2-3 years old discussions about this with no real solution. I had to google this and visit an external site, wow!
So glad to hear that this helped!