Replacing Links issue - @domain.local part 2

Q: Date/Time this occurred (Provide your time zone also)
A: 2/13/2024 11:00am EST

Q: DevKinsta Version
A: Version 2.13.1 (2.13.1.8585)

Q: OS Version
A: Mac OS 13.6.4 (22G513)

Q: Docker Desktop Version
A: 4.27.2 (137060)

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

Q: Detailed Description of the Problem
A:
Replacing Links issue - unfortunately this still appears to be happening. here’s how i can reproduce it: click add a site in devkinsta, import from kinsta, import from LIVE env. that creates the brand new site/app locally and i open it up and things work fine (mailto links appear as @domain.com). then when i pull a subsequent time, the PULL from LIVE is writing over data - what i can see is the email address domains are changing from @domain.com to @domain.local on any subsequent pull. maybe there’s two separate bits of code and it got fixed in the ADD NEW SITE pull from LIVE, but not in the PULL FROM LIVE sync code?

Hello @jakeatplace Jake :wave:

Thank you for reporting this issue!
I could replicate the same process as you reported above! :bowing_man: (and indeed my WP user’s email domain got replaced with the local domain URL after I ran a subsequent Sync → PULL from Kinsta - though the 1st “Import site from Kinsta” didn’t affect it at all) :sweat_smile:

I’ve passed this information to our internal DevKinsta devs team and will let them to review/recheck further. Hopefully they can find a solution to it and see if there can be fixed in the next deployment of DevKinsta version! :pray:

Best Regards,
Agus Utomo

1 Like

Hi @jakeatplace!

Our team has been further investigating into this matter, and we would like to gather a bit more information from you to ensure we understand the issue. To help us understand the issue better, could you please provide more details about the specific problems or disruptions you are facing when the local email address is updated?

We understand that the inconsistency between the initial site import, and subsequent pulls can cause confusion. We are looking into ways to address this. However, we do want to ensure we fully understand the exact issue you are experiencing due to how DevKinsta handles the initial import vs the subsequent pulls. This will help us in determining the best solution in this case.

We look forward to hearing from you!

Hi @Andrew - thanks for replying. Sure…so I just ran through it one more time to be sure. So I 1) took a brand new “Add New Site” pull from LIVE to local and confirmed the emails were good (@domain.com), then I 2) did a SYNC pull from live and confirmed it changed the addresses to @domain.local. The real problem happens after that step when I decide it’s time to deploy. I have a Kinsta cloud “dev” environment hanging around and when I do a SYNC push to dev, it writes the email addresses as @dev-env-url.kinsta.cloud. We’ve encountered the @dev-env-url.kinsta.cloud in our MAILTO links frequently in production (for right now I’m not willing to push to LIVE this way for obvious reasons, but you should be able to reproduce. It’s when the @domain.local rewrite is introduced, that it seems to carry forward through all environments local to cloud. I hope that helps.

Hi @jakeatplace!

Thank you for your reply, and explanation of the issue you are experiencing. I can certainly understand having the MAILTO links frequently be incorrect once the site has been pushed to the live environment would be problematic. We definitely want to ensure that this issue is resolved!

Just to confirm I am understanding correctly, when you SYNC pull from live the email addresses are updated to domain.local from your actual live domain name?

Then, once you push from DevKinsta to your dev site on MyKinsta the MAILTO domains are updated to @dev-env-url.kinsta.cloud, is that correct?

Then lastly from within MyKinsta when you push from that dev environment to live some of the MAILTO email addresses are not properly updated resulting in the email addresses remaining @dev-env-url.kinsta.cloud on the live website, is that correct?

We look forward to hearing back from you, and confirming the details!

Best regards

Yes, that’s right. Here’s maybe in a better format:

  1. Kinsta cloud: LIVE site is good - mailto’s reflect @domain.com
  2. devKinsta: Create new site, import from Kinsta LIVE - mailto’s reflect @domain.com on my mac
  3. devKinsta: Sync PUSH to Kinsta DEV cloud - mailto’s reflect @domain.com
  4. devKinsta: Sync PULL from LIVE (2nd ‘pull’) - mailto’s CHANGE - now reflect @domain.local
  5. devKinsta: Sync PUSH to Kinsta DEV cloud - mailto’s CHANGE on DEV - now reflect @dev-env-url.kinsta.cloud
  6. Kinsta cloud: PUSH to STAGING ENV from DEV env (as a non-prod test i just ran) - mailto’s REMAIN @dev-env-url.kinsta.cloud in STAGING.

I am happy to do a zoom call and demonstrate if that helps.

Thank you for your reply, and detailed explanation @jakeatplace!

We are only able to provide support via the forums for DevKinsta related assistance, or email and live chat for issues involving MyKinsta and managed WordPress hosting services. Therefore, we are unable to have a call over Zoom. However, I believe your explanation above will help us in determining the root cause of this issue and a solution.

I am going to be forwarding these details to our DevKinsta developer team to assist with the investigation. However, regarding the mailto issues involving the WordPress environments in MyKinsta please do reach out to our Support team via live chat within MyKinsta. Our team will be able to best assist you within a chat/ticket for this issue as it would relate to your managed WordPress service.

We will provide an update here though once we have an update regarding the mailto matter involving the DevKinsta side of things.

In the meantime, please don’t hesitate to reply if you do have any questions!

Best regards