(It seems the WP files get downloaded, but the db file, ie *.sql never gets downloaded or subsequently ran locally within the docker environment.)
Current workaround offered by@ David_Greene 1 month ago: of exporting db from phpmyadmin and then importing locally not really a viable solution for us unfortunately as we are currently in the process of evaluating managed hosting providers/wordpress dev op environments and not being able to easily create a local sandbox from a blank WP install makes Kinsta a difficult sell internally!
We will need to do this regularly with our staging/production sites. So any help in resolving would be very much appreciated and I will happily support with any log files required.
Hi @dgilfillan, thanks for reaching out.
We’re in the QA phase of a new release of DevKinsta that will fix this issue. I’ll be sure to notify you as soon as it is released!
You can actually see what’s happening if you navigate to your Kinsta site after a failed pull and view the “home” directory above ~/public. The database is being created there with a malformed name. You can also rename the file to backup.sql and move it to ~/public.
Again, this is one of the big fixes of the next release that should be out within a week.
I can confirm, on import I see a .sql with a malformed name.
I can rename it to “backup.sql” and place in the ~/public, but I’m not sure how that will help??? Are you saying I can then just import this file locally in adminer?
If it’s going to be fixed within a week, then may not need to spend too much time on it… just curious if I can manually complete, relatively quickly in the meantime.
Correct, if there isn’t already a malformed backup.sql in the home directory, you will have to Pull/fail first. Or you can just use the phpMyAdmin route and create a backup.sql and drop it into ~/public before you Pull the site. It’s basically the same process.
Am I correct in thinking that the phpMyAdmin route will require running a SQL command to rename intall? Whereas using the backup.sql file renaming should have already happened?
So the Search and Replace doesn’t happen until after the site files are pulled into DevKinsta/local.
Exporting the database to backup.sql from phpMyAdmin is just the manual way of doing what DevKinsta does. Both produce the same .sql file with no modifications yet.
am I correct in saying there is no way to actually “Pull” a site as such in DevKinsta correct? Rather you “Import” a site. So once I’ve attempted the first “Import” and created that backup.sql file remotely, I need to delete the site locally and “Import” it again (obviously after renaming and moving the backup.sql file remotely).
I may have noticed a bug in that when I “Imported”, I actually imported from my staging environment and yet the malformed backup.sql that got created did not get created in my staging environment, rather it got created in my production(live) environment?!
Yes that is correct; you’ll just have to try the process to get a handle on what’s going on.
That might be part of the bug, I never actually noticed that behavior, though. I’ll be sure our team tests this for the next release to make sure it isn’t happening still.
Unfortunately, the above steps are still unsucessful. The existance of the backup.sql file within the ~/public folder did not recreate the correct database. Rather strangely, a database from a previous backup of the site seems to have been used.
This process is definitely broken at this time. Please let me know as soon as the update comes out so I can test it.
Please also thoroughly test it yourselves before release to ensure the correct DB from the correct environment is downloaded and restored the DevKinsta site.