Subdomain Multisite Download from Kinsta Throwing Redirect Errors

Q: Date/Time this occurred (Provide your time zone also)

Q: DevKinsta Version

Q: OS Version

Q: Docker Desktop Version

Q: Were any error codes or messages observed? If so, what were they?
A: redirected too many times

Q: Detailed Description of the Problem
A: When downloading a Kinsta subdomain multisite from staging or live I am unable to open the main site and get a redirect error in the browser. I have tried this many times with several different multisite setups living within Kinsta.

Hi @ekline, thanks for reaching out!
I’m able to reproduce this and can confirm that it’s due to a known issue with the Search and Replace. You would need to use the database manager to edit the wp_blogs and and wp_posts entries. Those will need to use kinsta.local domain names.

The good news is that we are releasing a new version of DevKinsta very soon that should resolve this issue. I’m going to run some tests with the new release and make sure that this is fixed.

Please let me know if you have any questions!

1 Like

I just did this and am still running into the issue. Is this not resolved?

Hi @mwalcott; this specific issue was resolved with a previous update.
Can you provide more info about your issue? What OS are you using?

I just installed everything today so the most up to date versions. I then created a multisite on Kingsta and tried to pull it down to my windows machine. Then once completed I got the too many redirects error.

Is there any additional info you need?

Can you check the wp-confing.php file on your local machine? Is it still referring to the staging site?

Also in the database, are wp_blogs and wp_site not being updated to the .local domain?

There is a different database-related issue happening with the current Windows version that could cause this. The good news is that the next DevKinsta release with the appropriate fix will be coming out either this week or next week.

I can let you know once the new version has been released so that you can try again.

 * The base configuration for WordPress
 * The wp-config.php creation script uses this file during the installation.
 * You don't have to use the web site, you can copy this file to "wp-config.php"
 * and fill in the values.
 * This file contains the following configurations:
 * * Database settings
 * * Secret keys
 * * Database table prefix
 * * Localized language
 * @link
 * @package WordPress

// ** Database settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define( 'DB_NAME', 'summitgeeks' );

/** Database username */
define( 'DB_USER', 'root' );

/** Database password */
define( 'DB_PASSWORD', '' );

/** Database hostname */
define( 'DB_HOST', 'devkinsta_db' );

/** Database charset to use in creating database tables. */
define( 'DB_CHARSET', 'utf8' );

/** The database collate type. Don't change this if in doubt. */
define( 'DB_COLLATE', '' );

 * Authentication unique keys and salts.
 * Change these to different unique phrases! You can generate these using
 * the {@link secret-key service}.
 * You can change these at any point in time to invalidate all existing cookies.
 * This will force all users to have to log in again.
 * @since 2.6.0
define( 'AUTH_KEY',          ' 
define( 'SECURE_AUTH_KEY',   '
define( 'LOGGED_IN_KEY',     '
define( 'NONCE_KEY',         '
define( 'AUTH_SALT',         
define( 'SECURE_AUTH_SALT',  '
define( 'LOGGED_IN_SALT',    '
define( 'NONCE_SALT',        
define( 'WP_CACHE_KEY_SALT', '


 * WordPress database table prefix.
 * You can have multiple installations in one database if you give each
 * a unique prefix. Only numbers, letters, and underscores please!
$table_prefix = 'wp_';

 * For developers: WordPress debugging mode.
 * Change this to true to enable the display of notices during development.
 * It is strongly recommended that plugin and theme developers use WP_DEBUG
 * in their development environments.
 * For information on other constants that can be used for debugging,
 * visit the documentation.
 * @link
define( 'WP_DEBUG', false );

/* Add any custom values between this line and the "stop editing" line. */

define( 'WP_ALLOW_MULTISITE', true );
define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', true );
$base = '/';
define( 'DOMAIN_CURRENT_SITE', 'summitgeeks.local' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );

/* That's all, stop editing! Happy publishing. */

/** Absolute path to the WordPress directory. */
if ( ! defined( 'ABSPATH' ) ) {
	define( 'ABSPATH', __DIR__ . '/' );

/** Sets up WordPress vars and included files. */
require_once ABSPATH . 'wp-settings.php';

I clicked on Database manager from the DevKinsta dashboard and see this.

Yes, sorry, it looks like it didn’t export the database, which is the current issue with Windows/DevKinsta.

You can wait until the new version is released or you can manually export the database from Kinsta/phpMyAdmin then import it into DevKinsta/Database manager. You would just have to manually update the table values.

I did find that if I create the site locally and deploy then everything works

Yes, I’ve only seen the issue with Kinsta → DevKinsta on Windows. I don’t think there are any issues going in the other direction.

This has been fixed and tested on the new version, though. We are just waiting for quality testing to be completed before the update is ready.

Ok thank you for the quick response. I appreciate it.

1 Like