Opened 14 years ago
Closed 11 years ago
#17168 closed defect (bug) (fixed)
redirect loop when accessing wp-admin/network/
Reported by: | chaos1 | Owned by: | 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)
Change History (25)
#2
@
14 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
@
14 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:
↓ 5
@
14 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?
#6
@
14 years ago
- Resolution set to duplicate
- Status changed from new to closed
answer is here: #17090
#8
@
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
@
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?
#12
@
13 years ago
We could do a strtolower on the HTTP_HOST in network.php when the network is being installed.
#15
follow-up:
↓ 16
@
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:
↓ 17
@
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
@
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.
#18
@
11 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.
- 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 - 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.
#20
@
11 years ago
If this is the right approach, we could probably wrap the path comparison with strtolower()
as well.
Related: #26403
#21
@
11 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.
Ask them to clear their cookies and log in again.