[wp-trac] [WordPress Trac] #26407: Match path with current site's domain before redirecting to current site's domain and path

[WordPress Trac]

#26407: Match path with current site's domain before redirecting to current site's
domain and path
--------------------------------------+------------------
 Reporter:  codix                     |       Owner:
     Type:  enhancement               |      Status:  new
 Priority:  normal                    |   Milestone:  3.9
Component:  Multisite                 |     Version:  3.8
 Severity:  normal                    |  Resolution:
 Keywords:  dev-feedback needs-patch  |
--------------------------------------+------------------
Changes (by jeremyfelt):

 * keywords:  dev-feedback => dev-feedback needs-patch
 * milestone:  Awaiting Review => 3.9


Comment:

 Our handling of domain and path routing needs to be improved all around
 and this is a situation we'll always want to account for.

 I'm going to go overboard a bit to try and think through this.

 We maintain an awareness of domains in 3 places.

 1. `$_SERVER['HTTP_HOST']` - the requested domain
 2. `wp_blogs.domain` - the domain assigned to a site
 3. `wp_site.domain` - the domain assigned to a network

 An unfortunate part at the moment is that we seem to rely on sites having
 the same domain (`wp_blogs.domain`) as their parent network
 (`wp_site.domain`). If networks are merged without some sort of manual
 update to `wp_blogs.domain`, then all bets are probably off.

 This shouldn't be the case. A request should be checked against
 `wp_blogs.domain` and `wp_blogs.path` to see if a domain and path
 combination can be found. At that point, we should assume the network's
 `$current_site` information as related through `wp_blogs.site_id`.

 * If a site with a matching `wp_blogs.domain` and `wp_blogs.path` isn't
 found, then we should move up a level and see if a network exists with a
 matching `wp_site.domain` and `wp_site.path`. [1]
 * If a match isn't found there, then we should change our redirect path to
 `/` and see if something matching `wp_site.domain` shows up.
 * If nothing is found there, then we should redirect to a designated
 primary network.

 Logic supporting this in `ms-settings.php`—or something better organized
 beforehand—would go a long way in allowing for an assortment of domains,
 subdomains, and paths at the site and network levels.

 I'm going to move this to 3.9 for discussion in the hopes that we can do a
 few things around domain handling.

 [1] We may need to consider what happens with the rest of the requested
 path at this point. If we can't 404 on a piece of content, and the request
 becomes a guess at a parent network, then the requested content should
 probably drop entirely.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/26407#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform