Database error when site not found in multisite

[spacedmonkey]

I am getting a "Error establishing a database connection" when I give my multisite a domain that doesn't exist. I am using subdomain install and giving it a domain that doesn't exist. After checking, both the $current_blog and $current_site variables are returning false. This means that the ms_not_installed() is being fired. Instead if should be getting to the code for detecting if site exists, redriects and the ms_site_not_found action.

[jeremyfelt]

This sounds like expected behavior if DOMAIN_CURRENT_SITE and PATH_CURRENT_SITE are not both defined to supply default network information.

If the load process cannot find a matching domain for a site or a network and has no default to fall back on, we assume that multisite is not installed properly and fire ms_not_installed().

When a network is found (or predefined) and a site cannot be found, then the ms_site_not_found action should fire as part of the wrap up process before we redirect.

[spacedmonkey]

You are correct, I am running domain mapping and those defines are not in place. However, in 3.8 which I was using before, if I gave Wordpress a url that wasn't in my network, it would redirect the network site, which was the correct behaviour for my needs. After upgrading it doesn't do this and gives a useless and incorrect message to the user. I also can do anything about it, as there are no actions to hook. Why did the behaviour change so much from different versions.

[jeremyfelt]

Replying to spacedmonkey:

if I gave Wordpress a url that wasn't in my network, it would redirect the network site

This is still expected behavior, but WordPress needs either DOMAIN_CURRENT_SITE and PATH_CURRENT_SITE to be populated in wp-config.php, $current_site to be populated through sunrise.php, or the $current_site global to be filled in via the lookup process so that it knows what network to redirect to.

Do you have a way of sharing your sunrise code?

[jeremyfelt]

I'm going to close this ticket out as it appears to be expected behavior. Please reopen if still looks like a bug exists.