I read through all the posts I could find regarding nginx configuration and redirects - I see here on this post that nginx configuration on Kinsta doesn’t carry over to DevKinsta, however, I am experiencing an issue that directly conflicts with that.
I had the Kinsta support team assist me in adding some geolocation based redirects to direct all users located outside the US away from some US-specific content pages, and now when I import the site in DevKinsta, I can’t access wp-admin or other portions of the site locally, as I get redirected to the staging or live url (depending on which environment I cloned). I looked at the .conf file for the site and can’t see any custom rules in there that would be causing this, and can’t figure out how to disable the redirects locally.
So it’s true that the MK server configurations are not copied over into DevKinsta but there are a few things that could be causing your redirect issues:
wp-config.php is redirecting to staging/live
You still have entries in your database for your staging/live site. Check wp_options and wp_blogs/wp_site if this is a multisite.
You have plugins or code within your theme that is causing the redirects. You can try disabling or plugins or renaming the wp-content/plugins folder to rule plugins out.
There isn’t much I can do to check your local files/setup but feel free to private message your staging URL to me and I can check to see if there’s anything there that could cause this redirect issue when you transfer to DevKinsta.
I know you have said that these configurations don’t copy over but I can’t think of anything else that would cause this, due to the following reasons:
I have checked wp-config and there is nothing in there redirecting to staging/live
If I clone the staging site, certain pages redirect me from local to staging, and if I clone the live site, I get redirected from local to live
The redirects don’t happen on all pages, the specific pages that are redirecting me are the same ones that were listed in what I had sent the Kinsta support team to implement on their side
I did a search of the local database for the staging/live url and found nothing
I can confirm there are no plugins with redirects enabled, as I disabled them all through the plugin before they were implemented into the Kinsta nginx config
The site was working fine locally up until the point when I re-imported it from Kinsta right after they implemented those redirects for me, and there were no other changes made
I will send you my staging URL privately but based on the above it does seem to me like the nginx config could be carrying over into DevKinsta somehow and that it is worth looking into that possibility.
Yes, that’s extremely odd. The Kinsta and DevKinsta NGINX setups are very different and as far as I know we haven’t started carrying over redirects from MK/NGINX to DevKinsta/NGINX.
I will test this possibility based on the redirects that were added to your NGINX configuration. Something you can also do in the meantime is ask our support to temporarily comment out those redirects so that you can try pulling your staging site over again. If it works, then your theory is probably correct.
The only other things I’ve seen pull over redirects are SEO plugins and ometimes if it’s a 301, it can be your browser cache causing the redirect (probably not the case but it’s worth testing other browsers/incognito).
I’ll do some testing with the NGINX configuration, though to see if it is being copied over.
Hi @laura_certn, I’ve verified that for me the NGINX configuration isn’t being copied over. You can still use Docker’s command line tool to check the configurations in /etc/nginx/sites/yoursitename.conf, though.
Can you try using curl to see if the redirect still happens? You can do this from the terminal on your local machine or through the Docker terminal: curl -I http://mysite.local/theurlthatredirects/
Does that still cause a 302? If so, please private message what is returned by the curl command. The headers might hold some clues as to what’s going on.
Thanks for your help! I tried running the curl command, and then also tried your suggestion of having the Kinsta support team temporarily comment out the nginx config on staging. When this didn’t resolve it, I decided to dig deeper into the SQL tables. I had originally done searches for the staging/live urls with the / on the end, as that’s how they appear in the browser, but upon further inspection after I had re-imported the staging site, I did end up finding that there were multiple instances of the staging url without / in the tables including WP_OPTIONS. So, it seems that the actual issue occurring here is DevKinsta not correctly replacing the urls in the database during import. I ended up running this command through DevKinsta’s database manager which resolved it in the end:
UPDATE wp_options SET option_value = replace(option_value, 'oldurl.com', 'newurl.com') WHERE option_name = 'home' OR option_name = 'siteurl';
UPDATE wp_posts SET guid = replace(guid, 'oldurl.com','newurl.com');
UPDATE wp_posts SET post_content = replace(post_content, 'oldurl.com', 'newurl.com');
UPDATE wp_postmeta SET meta_value = replace(meta_value,'oldurl.com','newurl.com');
Is this a glitch with DevKinsta? Replacing the staging/live urls with the local one used to work fine up until recently, is there something in particular that could be causing that to stop working, or any steps I can take to avoid having to manually do the find and replace myself after import?
Thanks for the update @laura_certn!
That’s really weird. This was an issue with an older version of DevKinsta but should be fixed in the current one. Are you on version 2.6.0?
If so I’ll look at your site configuration again and try to reproduce this. By the way, when you Pull the site, the main.log will actually tell you what search and replace was run on the database using “wp db search-replace.”
If for some reason wp db search-replace isn’t working on those tables/is returning an error then it could lead to this issue.
MyKinsta uses a different search and replace method so that would explain why the S&R works with Live/Staging.
I am on version 2.6.0. Thanks for the tip about the logs, it seems like a plugin is causing a Permission Denied error when the search-replace command is run. I will get in touch with the plugin developer about that as I am already in communication with them about another unrelated issue.