Downloading staging gives me live site

DevKinsta Bug Reports
1

Q: Date/Time this occurred (Provide your time zone also)
A:
Yesterday (4/22) many times
Q: DevKinsta Version
A:
Latest version (as of yesterday)

Q: OS Version
A:
Windows 10

Q: Docker Desktop Version
A:
Latest version (4.6.1 I believe)

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

Q: Detailed Description of the Problem
A:
When I pull the website from staging I get what appears to be the live website. I’ve tried multiple times but it keeps giving me the live data. Though when I go to the staging it’s just fine.

I recently had trouble updating docker from 4.3 up and finally was able to but now downloading the website I can’t get the correct site.

One thing I haven’t checked if it’s just the database incorrect or the files themselves.

**On my phone but it’s been days of doing this.

2

Hi @Andrew_Fair, thanks for reaching out!
Can you please share your main.log files with me? It will help me check which database is being copied over by DevKinsta.

3

Hey Kevin,
@Kevin
Will do!
I went ahead and tried a fresh pull this morning, deleted the old site, and pulled staging again.

Summary

main.log (299.7 KB)

4

So @Kevin I find this very strange, it appears to be that it’s replacing corewgthemework.local in this download. Which shouldn’t be the case.
This website was initially created by copying a website on Kinsta (we have a website we copy all our sites off of when we first start a development, has theme/plugins/basic settings/ saves time on setup). Though why is the Wp Site URL: this, it shouldn’t be?

[2022-04-25 11:44:28.213] [info]  [ProgressIndicator] { isFailed: false, isOpen: true }
[2022-04-25 11:44:28.337] [info]  [terminalExec] Child process exited with code 0
[2022-04-25 11:44:36.438] [info]  [importBackupToDb] Import db
[2022-04-25 11:44:36.438] [info]  [dockerUtil/getContainer] Get 'devkinsta_fpm' Docker container
[2022-04-25 11:44:37.459] [info]  [dockerUtil/getContainer] Get 'devkinsta_fpm' Docker container
[2022-04-25 11:44:38.488] [info]  [dockerUtil/getContainer] Get 'devkinsta_fpm' Docker container
[2022-04-25 11:44:59.680] [info]  [wpGetSiteUrl] Wp Site URL: https://corewgthemework.local
[2022-04-25 11:44:59.680] [info]  [wpSearchAndReplace] Search and replace. Source: https://corewgthemework.local, to: http://allsteelconstruction.local
[2022-04-25 11:44:59.681] [info]  [dockerUtil/getContainer] Get 'devkinsta_fpm' Docker container
[2022-04-25 11:45:12.785] [info]  [updateWpConfigUrl]: update urls in wp-config.php. Site:allsteelconstruction from: https://corewgthemework.local, to: http://allsteelconstruction.local
[2022-04-25 11:45:12.786] [info]  [downloadSite] Site successfully downloaded
[2022-04-25 11:45:12.787] [info]  [addHostfileEntries] Start adding host entries
[2022-04-25 11:45:12.787] [info]  [hosts] Add host entries: [
  {
    "ip": "127.0.0.1",
    "host": "allsteelconstruction.local",
    "wrapper": "DEVKINSTA"
  },
  {
    "ip": "127.0.0.1",
    "host": "www.allsteelconstruction.local",
    "wrapper": "DEVKINSTA"
  },
  {
    "ip": "::1",
    "host": "allsteelconstruction.local",
    "wrapper": "DEVKINSTA"
  },
  {
    "ip": "::1",
    "host": "www.allsteelconstruction.local",
    "wrapper": "DEVKINSTA"
  }
]
5

When you Pull a site from Kinsta to DevKinsta, it should use whatever the site url is on Kinsta as the “From” when it runs the Search and Replace.

Is that log snippet for Staging → DevKinsta? It should be showing the kinsta.cloud domain unless you have that .local domain set within your staging’s wp-config.php or database.

Is corewgthemework.local mentioned anywhere on your Staging site? Within wp-config.php or the database? Please feel free to private message your full main.log file as well as the staging site URL and I can doublecheck as well.

6

Is there anyway we can open a chat and do this quicker? Haha I’m happy to provide any and all info.

I have tested multiple things now, my theory, though I have no idea how, is as follows.

This site, all steel, is cloned from another site corethemework which is on my kinsta account. I think this is the database from that and not from the live site at all.

Yes this is the staging.

I did another test, another site we just cloned:
Laster legal was cloned to make laster title

When I downloaded laster title it had the database of laster legal.

I feel it’s somehow saving the information from the site it was cloned from. The strange thing is my employee is not experiencing this issue.

Chat, call, meeting, anything I’d be open to discussing this quickly, my laptop works just fine but my desktop is having these issues and I can’t seem to figure out why. The only difference is that I did a decent amount of troubleshooting to get docker to work as after docker 4.3 it wouldn’t launch at all. So I was doing a lot like trying to remove all devkinsta files, removing all docker files as well.

Lastly that is the entire main.log file, that’s all of it. (In my first comment is the full main.log file)***

Hope I answered all questions, thank you for your help. Really stressful not to be able to work on my desktop.

P.s. I’m considering wiping my entire PC to attempt to fix this issue but really would prefer not to.

7

Huh, that’s very odd that your employee isn’t having the same issue. Everything DevKinsta does is purely based on file and database content. The database comes from the backup.sql file in ~/public. So I suggest looking into the backup.sql that’s being transferred and seeing if it’s the correct one. Basically just search for references to the incorrect site name. That’s where the issue would begin if it’s database-based. Also, maybe it’s because when you clone the site, it also clones the backup.sql file? Can you also try deleting the backup.sql file within ~/public before you try pulling the site over to DevKinsta? That probably still has references to the previous site.

We unfortunately do not have Live support for DevKinsta but if nothing else works, I would recommend completely uninstalling DevKinsta/Docker and reinstalling before going as far as wiping the PC. Maybe there’s something lingering on your PC, but I’m really at a loss as well.

8

I did a full PC wipe just now. Still same issue, fresh installed all my apps, docker, everything. Still downloaded the staging site and it’s incorrect.

The Backup.sql does indeed show the wrong URL. It shows the core themework URL instead of the allsteel URL. So is this looking for that URL on Kinsta hosting and then downloading that wrong database?

I’ll connect via SFTP and delete the backup.sql file and see what happens next.

9

I believe it has to do with how you are cloning the site; I don’t think DevKinsta is able to tell that you cloned it so it might not be regenerating the backup.sql for some reason. That’s just a theory, though.

I’ll need to try and reproduce this. If deleting the file doesn’t fix it then there might be something else at play. Either way, I’ll dig into this and bring it up with the devs if it’s a DevKinsta issue.

10

Update: @Kevin

I deleted the backup.sql on the staging server on Kinsta.

Now when I downloaded the site onto DevKinsta. It did the WordPress installation steps to create a new database/installation… :open_mouth:

11

Huh that makes no sense =/ Did it create a new backup.sql?

12

There is no backup.sql in the downloaded DevKinsta files. On the website SFTP there is not either, should I do a manual backup and see if that generates one?

13

So it sounds like for some reason DevKinsta isn’t triggering the backup.sql for you. That would explain why it wasn’t changing/fixing the cloned database.
Yes you can try a manual backup. DevKinsta tries to pull backup.sql from ~/public so as long as that’s there, it should transfer a database.

I’m trying to figure out why that isn’t triggering for you.

14

Can you share the main.log from this attempt as well?

15

Update:

So I asked my employee to download it after I did. He got the correct version. Then I deleted mine and redownloaded and now it worked. There is also now a backup.sql in the staging site of Kinsta.

Here is the main.log

main.log

main.log(hidden)
main.old.log(hidden)

1 Like
16

Thanks for all the help here @Andrew_Fair
It looks like this is partly due to a change that was made recently to MyKinsta. It’s having an adverse effect on DevKinsta processes. I’m going to coordinate with our Dev teams to get this resolved.

You’ll find that the backup.sql was created a directory above ~/public on your Staging site with a messed up name. That’s the most likely culprit for all these issues. Since the .sql file isn’t being generated in ~/public, it never reaches DevKinsta.

I’ll update here when this is resolved. Thank you again for your patience with this!

1 Like