Q: Date/Time this occurred (Provide your time zone also) A:
12/1/2022 Tokyo time zone
Q: DevKinsta Version A:
Latest
Q: OS Version A:
Win 11 latest
Q: Docker Desktop Version A:
v20.10.11
Q: Were any error codes or messages observed? If so, what were they? A:
None
Q: Detailed Description of the Problem A:
I have a local copy of a live staging site installed. I used push to staging from my local back to the staging (after doing a bunch of work) and to my surprise I found that url’s are not being replaced, they still point to my local site. I was expecting a search and replace to be done automatically, as it is done when you pull the site down (which worked fine). To not do them the other way is more than strange.
The site in question is a Generatepress site.
You can see in the image below the URL in the image is still a local version.
This sounds like it’s related to the current Search and Replace issues that our developers are aware of/looking into. Please let us know if manually running a Search and Replace within MyKinsta doesn’t fix this for you. If it doesn’t, then there may be an issue with how those urls are saved to the database/that not working with our Search and Replace method.
Here’s another one that didn’t get changed in Push to Staging. You can see the browser URL is the staging site, but the actual url for the image is still the local image url. It’s frustrating, as it seems to do most, but not all.
I don’t understand why it’s returning 70K+ results on the non-quoted string, I’ve only pushed it to staging twice and it doesn’t have that many references.
So a great way to see why it’s doing this/what some of the actual results are would be to use phpMyAdmin’s search in your Staging Environment
I believe the issue with your quoted string is that it’s actually ""https://blackopaldirect.local
I don’t see an exact string match for “//blackopaldirect.local” unless I’m just looking at the wrong spot.
You can verify by going to the wp_posts table in phpMyAdmin to view the actual contents of that post.
The amount of missed entries does tell me that it’s definitely due to the DevKinsta search and replace bug, though. Those should have all been replaced correctly.
Since the issue has reached your Staging environment you can contact our Live support team from within MyKinsta and they would be more than happy to help you get those .local entries sorted. I’m not too certain what is happening with WP MigrateDB Pro, but our support team can hopefully point you to the errors.
I have the same problem and I think it’s affecting not only images. I have to completely replace the DB after pushing to staging and then run both Kinsta Search & Replace tool as well as other search and replace tools on the theme and plugin files.
Whilst this bug is in place what is the easiest method to migrate sites. Seems that all the migration plugins I use (All In One Migration or Duplicator Pro) are banned by Kinsta or affected by max file size limits which is annoying and time consuming to work around.
I’ve replied to another thread you posted earlier (for the similar case) and we may continue there instead - to avoid double posts (same case) in multiple threads.
- to avoid double posts (same case) in multiple threads.