7

I have recently set up a second blog on my Wordpress multisite. The primary blog on the Multisite is www.example.com, and the second blog I have set up two days ago is www.example2.org.

Unfortunately, when going to www.example2.org, WordPress redirects to https://www.example.com/wp-signup.php?new=

On the same server, I have set up a corresponding test Multisite, with test.example.com being the primary blog and test.example2.org the second blog. It is working without a problem.

The Multisite-related .htaccess and wp-config.php settings are the same for both the test and the live Multisite, so that wouldn't be the problem. I've also verified that on the live Multisite I have www.example2.org correctly set in the wp_blogs table, and also it is correctly set as https://www.example2.org on the siteurl and home rows of the wp_2_options table (the _2_ part corresponding to the blog ID on the Multisite).

I would appreciate any suggestions on why this redirect is happening and/or how to resolve it. I don't even know which file is issuing the redirect (I don't think it's wp-signup.php) so I can't look at the relevant code to debug it further.

3

After many hours of debugging and despair, the problem is now solved. It turned out to be a very obscure thing.

The redirect is issued by the function ms_load_current_site_and_network() inside /wp-includes/ms-load.php. It was issuing the redirect because /wp-includes/ms-settings.php was not able to set a domain. The reason it was not able to set a domain is because $_SERVER['HTTP_HOST'] was not set.

$_SERVER['HTTP_HOST'] not being set had to do with the PHP setting auto_globals_jit. It was set to On, resulting in the $_SERVER array not being set (as explained in this comment). Even though $_SERVER['HTTP_HOST'] and the rest were defined when loading a single php file with phpinfo(); in it, they were not defined when loading Wordpress's php files. And that led to the redirect.

Setting auto_globals_jit to Off in php.ini resolved it.

Bonus info:

The issue was additionally made more complicated by some form of caching (which I couldn't pin down or clear). So I had to rely on behavior that I saw occur only once and couldn't replicate afterwards. For example, I created a separate php file to just check if $_SERVER['HTTP_HOST'] is set - and initially it wasn't. Following the suggestion from the comment, I used $_SERVER['HTTP_HOST'] twice in the php file - and immediately saw that it was now set. However, when reverting the change and having $_SERVER['HTTP_HOST'] only once in the php file, it still remained set - suggesting I was seeing a cached response. I coulnd't get it to break again after I fixed it once.

Just documenting this here in case someone encounters similar behavior.

| improve this answer | |
  • 1
    I want to thank you for doing the deep digging to find this bug. I have been wresting with the same issue for a while now and I was finally able to come across an answer that at least addressed the issue. – Brent Jul 17 '18 at 16:26
2

I can't comment so I'm leaving this answer. As a follow up to the fantastic research done by @Borislav there is another SE thread that is related, with several potential fixes:

Site Redirecting to wp-signup.php

Ultimately, all the redirect issues with WordPress Multisite seem related to siteurl and home which even if properly hardcoded (e.g. using WP_HOME and WP_SITEURL in the wp-config.php file) will still result in redirect issues if the accompanying fields in wp_options table are not also correct. This is due to the way that WordPress Multisite processes the initial setup routine; while I haven't found any documentation on the reason for this, I believe it was probably done on purpose by a Core dev to ensure no conflicts arise later on in the functionality of the Multisite installation, which is more prone to issues than single sites.

Some have suggested implementing NOBLOGREDIRECT as a fix but this does not seem to work, and does not address the underlying issue. That setting is only meant to redirect visitors who land on non-existent sub-sites of your Multisite network (e.g. if registration is disabled for new blogs).

Ref: https://www.sarahgebauer.com/today-i-learned-multisite-mystery-signup/

Ref: https://gist.github.com/dejanmarkovic/8323792

In conclusion:

Always ensure that your wp_options table has the siteurl and home settings updated to accurately reflect the main domain of your Multisite installation. In certain cases, running a search/replace across the entire MySQL database may be required, depending on the history of your domain (and database), in particular to target incorrect entries in the wp_blogs and wp_site tables...

| improve this answer | |
  • 1
    This was a huge help!! I definitely found until I had updated the wp_blogs and wp_site tables, that the redirect would not go away. I wish this answer was ranked higher and also was on the other Stack Exchange answer you linked above which I had also gone to first and found nothing worked. – Trevor Oct 30 at 10:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.