Resolving The WordPress Multisite Redirect Loop

This is a re-post from an original article by Tom Mcfarlin located here

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

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:

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.

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:

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.