Make WordPress Core

Opened 13 years ago

Closed 10 years ago

#17168 closed defect (bug) (fixed)

redirect loop when accessing wp-admin/network/

Reported by: chaos1's profile chaos1 Owned by: nacin's profile nacin
Milestone: 3.9 Priority: normal
Severity: normal Version: 3.1.1
Component: Bootstrap/Load Keywords: has-patch
Focuses: multisite Cc:

Description

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.

Attachments (3)

17168.diff (484 bytes) - added by wpmuguru 13 years ago.
17168.2.diff (692 bytes) - added by jeremyfelt 10 years ago.
17168.3.diff (700 bytes) - added by jeremyfelt 10 years ago.

Download all attachments as: .zip

Change History (25)

#1 @scribu
13 years ago

Ask them to clear their cookies and log in again.

#2 @jamesmehorter
13 years ago

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.

#3 @ryan
13 years ago

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.

#4 follow-up: @chaos1
13 years ago

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?

Last edited 13 years ago by chaos1 (previous) (diff)

#5 in reply to: ↑ 4 @greuben
13 years ago

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.

#6 @looklab
13 years ago

  • Resolution set to duplicate
  • Status changed from new to closed

answer is here: #17090

Last edited 13 years ago by scribu (previous) (diff)

#7 @ocean90
13 years ago

  • Milestone Awaiting Review deleted

#8 @chaos1
13 years ago

  • Resolution duplicate deleted
  • Status changed from closed to reopened

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

#9 @chaos1
13 years ago

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?

Last edited 13 years ago by chaos1 (previous) (diff)

#10 @scribu
13 years ago

  • Milestone set to Awaiting Review

#11 @scribu
13 years ago

  • Keywords dev-feedback added; reporter-feedback removed

#12 @wpmuguru
13 years ago

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

@wpmuguru
13 years ago

#13 @wpmuguru
13 years ago

  • Keywords has-patch needs-testing added; dev-feedback removed

#14 @DrewAPicture
12 years ago

  • Version set to 3.1.1

#15 follow-up: @tobias
12 years ago

  • Cc t@… added

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' ]');

#16 in reply to: ↑ 15 ; follow-up: @wpmuguru
12 years ago

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.

#17 in reply to: ↑ 16 @tobias
12 years ago

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
10 years ago

#18 @jeremyfelt
10 years ago

  • Milestone changed from Awaiting Review to 3.9

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.

#19 @jeremyfelt
10 years ago

  • Component changed from Multisite to Bootstrap/Load
  • Focuses multisite added

#20 @jeremyfelt
10 years ago

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

Related: #26403

@jeremyfelt
10 years ago

#21 @jeremyfelt
10 years ago

  • Keywords needs-testing removed

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.

#22 @nacin
10 years ago

  • Owner set to nacin
  • Resolution set to fixed
  • Status changed from reopened to closed

In 27725:

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

props jeremyfelt.
fixes #17168.

Note: See TracTickets for help on using tickets.