I probably spent too many hours today deleting cookies and restarting my browser, trying to figure out why logging into my WordPress multisite network kept redirecting me back to the login page.

I would get no feedback on the login failure, save for a mysterious value in the query string named reauth set to a value of 1 (true). The morning was spent cutting and pasting echo statements along the execution path of the code. Eventually, I traced the problem to the cookies set by WordPress. All I had to do was delete them to get the authorization back on track. Or so I thought.

There was just one problem — I use subdomains of my production instance to spin off my development instance. It’s a naming convention I employ with everything — if production is located at vigilantmedia.com, then test is available at test.vigilantmedia.com and development at dev.vigilantmedia.com.

In this case, blog.vigilantmedia.com is my production instance, and development was dev.blog.vigilantmedia.com. Nice and consistent, right?

Not for WordPress.

WordPress sets cookies with a leading dot in the domain name, thus the cookie for blog.vigilantmedia.com can be read by dev.blog.vigilantmedia.com. I guess it’s necessary for the way WordPress uses subdomains for a multisite network, but it’s terrible when subdomains are used to distinguish environments.

In my case, I would encounter a redirection loop if I logged into production before I logged into environment, but I could avoid the loop by logging into development before production. The state of one should never be dependent upon the other.

As a result, I’ve had to break my domain naming convention and use a different subdomain for my development instance. I won’t even go into all the myriad ways these shared cookies mess up domain mapping. It’s not pretty.

I like to make the differences in my development, test and production environments as minimal as possible — a reason I dislike using localhost on my local machine for development — but the architecture of WordPress makes that difficult.

I probably wouldn’t encounter these problems if I put each blog in its own instance, effectively duplicating resources. Movable Type does a far better job of creating networks — the schema is designed for it. The WordPress schema for its networks smells of monkeycode.

There is definitely room for improvement.