I’m having an issue when pulling a WordPress site from Kinsta into DevKinsta. Instead of behaving like a normal pulled environment, the site shows up as a “Custom Site” and keeps redirecting to the live domain rather than staying on the local *.local URL. The files and database appear to import, but the local site won’t load correctly without redirecting externally. I’ve checked basic settings but it still seems tied to the production domain. Has anyone run into this before or know what settings or search-replace steps I might be missing to keep it fully local?
Its only 1 website. All other site pull and push correctly.
It’s possible that you have update_option(siteurl) and update_option(home) in the theme files, code, leftover cache folder or another code that would direct to the live site.
I’m glad to hear that define override works If it’s it’s just one site with this issue, it’s unlikely that something’s wrong with your setup (DevKinsta/Docker) and more likely to be site-specific.
update_option(siteurl) and update_option(home) hasn’t been added to funcations.php or any custom plugins. Currently there are no custom plugins on the site in question.
I will continue to use WP_HOME WP_SITEURL from the time being
WooCommerce stores a lot of settings and links that are tied to the site’s URL. When you copy the site to a local environment (crofts.local), those links still point to the live site. This can cause the admin dashboard to look broken, menus missing, or login not work — even if the frontend appears fine. Trying to “fix” it by changing URLs in the database can accidentally break WooCommerce settings, because some data is stored in a special format. The safe way is to keep the database as-is and use a small local configuration tweak so WooCommerce knows it’s running locally. Live site stays untouched — only the local copy is affected.
The search-and-replace functionality in the database should be included when performing a Push/Pull site action between DevKinsta and Kinsta hosting. It’s possible that our Search and Replace script was unable to update the live site URLs due to an uninitialized class or the use of non-standard Regex syntax in the domain entries. You may provide us with the live site domain so we can investigate further. Alternatively, you can try to manually run a Search and Replace using WP-CLI within Docker Desktop.
You can send me the current domain being used on the site you’re trying to pull from the Kinsta server via private message. No need to send me any login info.
Thank you for sharing the domain of the Kinsta site you’re trying to pull into DevKinsta. I reviewed the domain entries in its database, and it seems they are using a Regex format for the domain entries:
'https:\/\/domain.com'
Due to this unique format, the search and replace function when pulling or pushing sites will not include these entries. This format appears to be managed through Elementor, which has a built-in Search and Replace feature. Unfortunately, when you pull or push the site between DevKinsta and the Kinsta server, you will need to perform an additional Search and Replace using Elementor to ensure that no leftover entries from the source domain remain.
Even when I add the following to wp-config.php I still cannot login to perform the Elementor search and replace. I am continuously redirected to the Live domain.
It could be that the custom login setting is still referencing the live domain in the database. Since custom login URLs are typically managed by plugins, they may contain domain entries in formats that are not automatically replaced during the DevKinsta pull process and the reason why accessing the custom login URL redirects to the live site, while /wp-admin works normally.
I have direct messaged you both main.log and main.old.log.
I have also tried deleting WooCommerce and then pulling the site to DevKinsta. The site still appears as custom site and is unusable. I have attached a screenshot here of the wp-config file which is defiantly incorrect. Even upon correcting it the site redirects to the live website.
If it’s it’s just one site with this issue, it’s unlikely that something’s wrong with your setup (DevKinsta/Docker) and more likely to be site-specific.
