WordPress is acting like it’s not installed and giving me the ERR_TOO_MANY_REDIRECTS error.

Here’s what I did to create the error

Basically I was trying to update Ubuntu from 18.04 to 20.04 on my site and decided to start with the staging environment. I basically did the following:

  1. Created new droplet
  2. Made new group_vars for it copying staging group_vars over
  3. Provisioned and deployed to new server
  4. Exported DB from Staging and Imported into new site
  5. Ran search and replace for new domain name on each site with wp search-replace --url="sitedomain" and also for the network itself with wp search-replace --network
  6. rsynced the uploads directory to the new server
  7. Tried to go to site and was warmly greeted with ERR_TOO_MANY_REDIRECTS.

Here’s the multisite specific wp-config I have:

 * Multisite
define('WP_ALLOW_MULTISITE', true);
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', true); // Set to true if using subdomains
define('PATH_CURRENT_SITE', env('PATH_CURRENT_SITE') ?: '/');

 * Multisite: Get TLDs to work
define('ADMIN_COOKIE_PATH', '/');
define('COOKIEPATH', '');
define('SITECOOKIEPATH', '');

 * Use the current HTTP host as the cookie domain. This ensures cookies and
 * nonces are using the correct domain for the corresponding site. Without
 * this, logins, REST requests, Gutenberg AJAX requests, and other actions
 * which require verification will not work.
define('COOKIE_DOMAIN', !empty($_SERVER['HTTP_HOST']) ? $_SERVER['HTTP_HOST'] : '');

Here’s the URL Structure

Some additional context is that on this is a multiple TLD multisite setup. So in this context that looks like:

Additional Context

I’ve also got the roots/multisite-url-fixer mu plugin installed.

Some of my investigation uncovered that whatever redirect loop is happening is happening before the muplugins_loaded action even fires. So I don’t know how much help the roots/multisite-url-fixer plugin is anyways with this issue.

It seems the site redirects to /wp-signup.php?new=<site-domain> (which notably is not /wp/wp-signup...) and then gets caught in the redirect loop there.

I’ve honestly no idea what else I could do. I’ve looked at every related forum post and google listing I could find, with no avail.

Anyone have any idea what I could be running into?

The site redirecting to the sign up page is likely due to WordPress not knowing about your site, and is therefore prompting you to configure one.

I’d suggest modifying your multisite config to:

Config::define('WP_ALLOW_MULTISITE', true);
Config::define('MULTISITE', true);
Config::define('SUBDOMAIN_INSTALL', true);
Config::define('PATH_CURRENT_SITE', env('PATH_CURRENT_SITE') ?: '/');
Config::define('SITE_ID_CURRENT_SITE', env('SITE_ID_CURRENT_SITE') ?: 1);
Config::define('BLOG_ID_CURRENT_SITE', env('BLOG_ID_CURRENT_SITE') ?: 1);

Config::define('COOKIEPATH', '/');
Config::define('SITECOOKIEPATH', '/');
Config::define('ADMIN_COOKIE_PATH', '/');
Config::define('COOKIE_DOMAIN', $_SERVER['HTTP_HOST']);

I would then check the wp_blogs table in your database to ensure it looks like:

| blog_id   | url                  | path |
| 1         |  | /    |
| 2         |  | /    |

Check your wp_site table looks like:

| site      | url                  | path |
| 1         |  | /    |

Check wp_sitemeta has the following:

| option_name       | value                             |
| siteurl           | http(s)://  |
| subdomain_install | 1                                 |

Check wp_options has the following:

| option_name   | value                             |
| siteurl       | http(s)://  |
| home          | http(s)://  |

Check wp_2_options has the following:

| option_name   | value                           |
| siteurl       | http(s)://  |
| home          | http(s)://  |

As you have been redirected several times your browser will cache this so ensure you clear your cookies / disable local cache. Or use curl -i for debugging redirects.

I would first disable the multisite URL fixer too, and enable once you’ve hit your homepage on both sites.

Finally make sure your Trellis wordpress_sites.yml config is correct. I suspect that when you have performed your rewrites, you have rewritten URLs twice.

When rewriting with WP CLI, you have to remember that there are two types of url, so a network rewrite after a normal rewrite can be quite destructive. For example:

wp search-replace

Followed by:

wp search-replace --network

Will result in some tables having and some having


This solved it. Specifically it was database issues. When I ran the search and replace I did it like so:
wp search-replace '//' '//' --network
wp search-replace '//' '//' --url=""

The // I included because I didn’t want to run into the duplicate subdomain issue you mentioned. But that had a side effect of not updating wp_site and wp_blogs since those tables don’t include the protocol scheme in the values.

Thank you so much for you’re help!


Brilliant glad I could help! I find doing multisite rewrites like this seems to hit the least issues:

# Tackle the sitemeta and first site options table
wp search-replace wp_sitemeta wp_options

# Tackle blogs and site table
wp search-replace wp_site wp_blogs

# Tackle the HTTPS rewrites in all tables - covering content rewrites
wp search-replace --network

# ----------------------------------------------
# Thats the main site done, now we need to tackle the other URLs - rinse and repeat these for each sub site
# ---------------------------------------------

# Change the url in the blogs table
wp search-replace wp_blogs

# Change all URLs for that site
wp search-replace --network