Replacing Links issue

Q: Date/Time this occurred (Provide your time zone also)
A: 7:00pm EST

Q: DevKinsta Version
A: 2.10

Q: OS Version
A: 13.4

Q: Docker Desktop Version
A: 4.19

Q: Were any error codes or messages observed? If so, what were they?
A: no

Q: Detailed Description of the Problem
A: I pulled database from live to local, and push the database to staging and in the processes of replacing links it also replaced all the users company email to the URL [chase.gordon@httpsstg-r3com-staging.kinsta.cloud]

Iā€™m currently running a new sync down and pushing up to staging again to see if the issue presists.

The issue happened again and I needed to write a SQL script to search and replace the userā€™s email addresses on staging.

Looked at the local database synced and at the user table: chase.gordon@https://r3com.local.

Hi @monofrio ,

Thank you for reporting this issue.
I was able to replicate it on my end as well.

Iā€™ve checked the process in the main.log file on my computer, and I noticed that it seems what is happening here is: the Sync process (ā€œpull and/or pushā€) of the site is running through a WP Search and Replace of the entire database (all tables) for the site to be able to viewed locally (with the .local domain URL).

This ā€œsearch and replaceā€ process also ensures that all the internal links are using something like thesitename.local domain to make it viewable when clicking around in the web browser. Though this WP ā€œsearch and replaceā€ process is also catching the email@domainname address if it matches the siteā€™s domain name.

So for example, if the email in the database uses: user@sitedomain.com (and the live site URL is: sitedomain.com ), that email address would be affected during the WP search-replace process - and would be then showing this in the database: user@https://sitedomain.local
(while the site domain URL would be replaced properly, like from https://sitedomain.com to https://sitedomain.local , which is correct).

As a workaround (other than with that SQL script method you mentioned), after you synced (pushed to Staging), you could also use the ā€œSearch and Replaceā€ tool in MyKinsta (on Staging environment) and may want to search for that incorrect email address (e.g.: chase.gordon@https://r3com.local) and replace it with the correct email address (e.g.: chase.gordon@domainname.com).

Hope that helps!
Regards,
Agus

I see that as an issue if I need to constantly run a script if I need to pull to local and push to staging with the live data. I did run a SQL replace function on the user_name table to does resolve this issue. Will there be some kind of rule to prevent the search and replace on this table. It really shouldnā€™t get replaced.

Thanks
Mark

Hi @monofrio, once youā€™ll push from staging to live the email addresses will be fixed with the right domain.
Depending on the case of use, someone would prefer a partial search and replace that excludes the email addresses (like you) while others might prefer to find any reference to a domain and replace it with something else.
Iā€™ll pass to our devs a feature request, perhaps this might be a setting that can be enabled/disabled with a checkbox based on the user preference. Our dev team will review and discuss the ways and means of it and see if it can be implemented one dayšŸ‘

Regards,
Alessandro

Thank you, That would be great because I have my team go on the staging to build out and test on the frontend, and they need to have access to there work email addresses.

1 Like

I want to highlight another consequence of this issue - in addition to replacing email addresses in the site content, it appears to be replacing SMTP credentials in settings (in our case, WP Mail SMTP had the ā€œfromā€ address as well as the ā€œusernameā€ settings erroneously updated).

For example: ā€œno-reploy@mysite.comā€ had been replaced with ā€œno-reply@https://mysite.comā€ which obviously broke production email sending.

1 Like

Kinsta: Iā€™m still fixing issues with our transfer from staging to live. There really should be a rule because we also house a bunch of different subdomains as microsites, and our CRM integration and other miscellaneous links all got broken. Also, we have our main domain as naked, meaning it does have the ā€œwwwā€ in front of it, and we found that it added this to some URLs as well. I shouldnā€™t have to search and replace this:

  • https://www.https:// ā†’ https://
  • hub.https:// ā†’ hub.
  • Info.https:// ā†’ info.
  • and more

There needs to be some way not to have subdomains or emails affected by migration up or down from live.

Mark

Hey Mark,

as I understand it the issue with the www appeared when you pushed from local to staging, am I correct? If so, can you please share via DM the name of the staging site so I can take a look at the action on our side?

Regards,
Alessandro

stg-r3com-staging.kinsta.cloud

@monofrio Unfortunately the event is too old to be checked on this side. Would you be able to send us a copy of the main.log file via DM so we can review the search and replace terms? You can find it by clicking on the question mark icon at the bottom left corner of DevKinsta and then on Reveal log file in File Manager.

Regards,
Alessandro

Hey @ransom Iā€™m checking this issue with our developers as I was able to replicate it on my test site. Weā€™ll keep you posted!

Regards,
Alessandro

hi there. any update on options on push from devkinsta to other envā€™s on kinsta.cloud? from what iā€™ve been told the deploys within kinsta cloud do not search and replace when thereā€™s an ā€˜@ā€™ (only on domains without a preceeding @). the regex used from staging.kinsta.cloud to LIVE is ā€œ/(?<!@)domain[.]comā€ - so can that be at least an option on devkinsta? having to always search/replace when using devkinsta is a broken experience.

Hi @jakeatplace :wave: Welcome to the Kinsta Community!

Iā€™m pleased to inform that as of DevKinsta version 2.12.0, we have successfully resolved the search and replace issue involving @domain.com during push/pull action. The latest DevKinsta version, 2.13.1 is also now available for download. Moving forward, if your domain contains the ā€œ@ā€ character before it, it will be excluded from the search and replace action.

We are confident that this update will significantly enhance your experience with DevKinsta. If you have any questions or feedback, feel free to post on this forum. We will be here to assist.

3 Likes

fantastic news! thank you!

2 Likes

Youā€™re most welcome Jake! :smile:

Since the issue has been resolved in that latest DevKinsta released (mentioned above), I will mark this thread as resolved! :+1:

Best Regards,
Agus Utomo

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.