Match path with current site's domain before redirecting to current site's domain and path

[codix]

It would be better if current blog cannot be found with given domain and path to try to match with $current_site->domain and given path before redirecting to $current_site->domain $current_site->path .

[jeremyfelt]

Thanks for the patch, @codix.

If I'm reading this correctly, it doesn't seem that any behavior in core would change. In a subfolder installation of multisite, $domain and $current_site->domain are currently the same.

Can you provide more detail around the issue that needs to be solved?

[codix]

It's not the typical use case.

1. If two networks are merged into one with non conflicting blog names. If users try with the old domain but correct blogname they get redirected to main site, with suggested change they get redirected to the correct blog
2. In a multi domain setup users can mix up the domains and (e.g. example.net/myblog instead of example.com/myblog) they get redirected to main site, with suggested change they get redirected to the correct blog.

Thanks!

[jeremyfelt]

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.

[jeremyfelt]

Rereading the original description and the followup, I'm not confident this is something we can account for in core. If we receive a request for a domain that is invalid, we can't guess at a best replacement. It does sound like something that can be handled in sunrise.php in the instance where networks have been merged together. It almost sounds like a domain mapping plugin is in use.

My previous comment became #27003, which is now in progress. Suggesting we close this as wontfix. Please feel free to expand on the thinking here, as it's entirely possible I'm missing something.

[jeremyfelt]

Closing this as wontfix. See progress in #27003 along with a future hook in #24113 to better customize these results.