redirect loop when accessing wp-admin/network/

[chaos1]

As of 3.1.1 administrators are getting redirect loops when accessing wp-admin/network/. I run a multi-site multi-domain network and we've noticed that this bug is effecting new and old sites. One super admin reported clicking Update Network put's it in a redirect loop as well.

For new sites if this bug occurs the quick solution is to delete / recreate. I checked _options siteurl, _blogs blog_id domain, and _sitemeta siteurl. Nothing out of the ordinary in the db.

[scribu]

Ask them to clear their cookies and log in again.

[jamesmehorter]

I also have the same exact issue. Ran the auto-update from 3.1 to 3.1.1. Update finishes fine. When asked to 'Update Network' the link results in an invalid redirection. Firefox says the following when clicking 'Update Network' at the top of the dashboard:

The page isn't redirecting properly
Firefox has detected that the server is redirecting the request for this address in a way that will never complete.
This problem can sometimes be caused by disabling or refusing to accept cookies.

Tried removing all cookies associated with the domain, and cleared cache. Same problem in multiple browsers. Each time I try to 'Update Network' a .maintenance file is placed in the site root rendering the site unreachable. Since the update fails I have to ftp in and remove the file to bring the site back up.

[ryan]

Network admin is forced to live at the root domain of the network. Do you have something redirecting the root elsewhere? You can try removing the redirect at the bottom of /wp-admin/network/admin.php.

[chaos1]

I asked Super Admin's to clear cookies / cache / private data. They responded that their still experiencing the redirection loop.

Afterwards: @Ryan - I've commented out the redirect (lines 18 - 21) in /wp-admin/network/admin.php and it resolved the issue. It must be network_admin_url() - I wonder why it gets thrown into this loop?

[greuben]

Replying to chaos1:

Afterwards: @Ryan - I've commented out the redirect (lines 18 - 21) in /wp-admin/network/admin.php and it resolved the issue. It must be network_admin_url() - I wonder why it gets thrown into this loop?

See #17090, I am 90% sure this is the same problem.

[looklab]

answer is here: #17090

[chaos1]

When I took a look through ​#17090 I uploaded and activated ​ticket-17090.2.php

According to nacin's ​comment #19 it is a path issue in $wpdb->blogs. Taking a look at the output below, the path is / - Note: Network admin URL and [domain] had capitalization in the original MyDomainName.com.

Output:

Attempted URL: example.com/wp-admin/network/
Network admin: true
Main site: true
Network admin URL: http://Example.com/wp-admin/network/
stdClass Object
(
    [id] => 143
    [domain] => Example.com
    [path] => /
    [blog_id] => 195
    [site_name] => Example
)
stdClass Object
(
    [blog_id] => 195
    [site_id] => 143
    [domain] => example.com
    [path] => /
    [registered] => 2011-05-19 19:31:43
    [last_updated] => 2011-05-24 17:38:32
    [public] => 1
    [archived] => 0
    [mature] => 0
    [spam] => 0
    [deleted] => 0
    [lang_id] => 0
)
stdClass Object
(
    [blog_id] => 1
    [site_id] => 1
    [domain] => parentdomain.com
    [path] => /
    [registered] => 2010-09-17 23:01:01
    [last_updated] => 2011-05-24 16:37:53
    [public] => 1
    [archived] => 0
    [mature] => 0
    [spam] => 0
    [deleted] => 0
    [lang_id] => 0
)
DOMAIN_CURRENT_SITE is parentdomain.com
PATH_CURRENT_SITE is /
SITE_ID_CURRENT_SITE is 1
BLOG_ID_CURRENT_SITE is 1

[chaos1]

I suspected that the capitalization in $wpdb->site may have fubared /wp-admin/network/, look at lines 14-15 in ​ticket-17090.2.php

I edited domain in $wpdb->site and change MyDomainName.com to mydomainname.com, low and behold it fixed the redirect loop! Has anyone else experienced this issue?

If I compare relevant tables between $wpdb->blogs and $wpdb-site, $wpdb->blogs domain is all lower case were $wpdb->site has capitalization. If I change $wpdb->blogs's to match caps (MyDomainName.com) in $wpdb->site the redirect loop is resolved. Vis-versa!

Where do we go from here?

[wpmuguru]

We could do a strtolower on the HTTP_HOST in network.php when the network is being installed.

[tobias]

We had the same or very similar problem with our multisite-installation that runs behind a apache rewrite rule. We ended up overwriting the $_SERVER[ 'HTTP_HOST' ] to work around it. See ​http://wordpress.org/support/topic/err_too_many_redirects-nur-unter-wp-adminnetwork for a complete description of the problem and solution.

I thing the best way to solve this in general ist, not to use variables like HTTP_HOST at all in the core but to base all core-feature on a variable like DOMAIN_CURRENT_SITE. Or if this is multisite-specific, then something similar that works for every site. It could also be a simple default inside wp-config with domain_current_site defaulting to http_host. This way it is only one place to fix the redirecting-problem. – Like this:
define('DOMAIN_CURRENT_SITE', '$_SERVER[ 'HTTP_HOST' ]');

[wpmuguru]

Replying to tobias:

I thing the best way to solve this in general ist, not to use variables like HTTP_HOST at all in the core but to base all core-feature on a variable like DOMAIN_CURRENT_SITE.

DOMAIN_CURRENT_SITE is not a required constant. Old MU installs will not have it nor will installs that are running more than one network.

[tobias]

Replying to wpmuguru:

DOMAIN_CURRENT_SITE is not a required constant. Old MU installs will not have it nor will installs that are running more than one network.

Why not introduce a new variable that is used for generating site-urls all over the core. And of course there needs to be a fallback for when the variable is not set. This fallback may very well be the HTTP_HOST variable. But this way there is only one place that needs fixing and it is easier to find.

I was could not really believe when I saw, that the wordpress-core has places where a site-url is generated all over the place. I am a little impressed that WP managed to manage so much redundancy (not DRY-ness). But I don't think it is good.

[jeremyfelt]

If I compare relevant tables between $wpdb->blogs and $wpdb-site, $wpdb->blogs domain is all lower case were $wpdb->site has capitalization.

This appears to be the key issue. If accessing example.com/wp-admin/network/, the domain in $wpdb->blogs must be an exact, case sensitive match of the site (network) domain. This is done first via DOMAIN_CURRENT_SITE and then $wpdb->site if that is not defined.

1. Domains are case-insensitive, so when doing any kind of comparison operation, it may make sense to strtolower() in wp-admin/network/admin.php#L18
2. It seems out of the ordinary that the same domain with mismatched case would end up in the database. It'd be nice to see how that happened.

At first glance it seems that the cleanest way forward is to fix the $current_site->domain and $current_blog->domain comparison. This resolves the likely cause of the issue without holding us to much more for the future.

17168.2.diff​ takes this approach.

[jeremyfelt]

If this is the right approach, we could probably wrap the path comparison with strtolower() as well.

Related: #26403

[jeremyfelt]

strcasecmp() seems cleaner for this.

17168.3.diff applies that to both the domain and path comparisons, eliminating the infinite redirect when domain or path with mismatched case is stored in the database.

[nacin]

In 27725:

Network Admin: Case-insensitive comparisons for the network-site comparison in the bootstrap.

props jeremyfelt.
fixes #17168.