I tried importing another site (not originally from Kinsta hosting) by structuring the files according to this previous post - what I thought I figured out, finally - but it did not work… maybe due to new version of DevKinsta???
I see Troubleshooting - Error Codes - Kinsta® Docs got updated with specifics about wp-config.php and *.sql which is awesome to see, but no combo worked for me. In all my variety of attempts, I never got past the first step to parse WP-Config.
Please try doing an import and let me know what .zip file+folder structure worked for you.
I’m sorry to hear that you are continuing to have difficulty with importing a new site from a backup in DevKinsta. I understand having this issue reoccur is frustrating. We certainly want to ensure you are able to import your site backups into the application!
To attempt to replicate the issue I just downloaded a backup of my site from MyKinsta, and was able to import it without error into the latest version of DevKinsta. The archive was laid out the same as we discussed earlier where the site files were inside the public folder, and the .sql database backup was located at the top of the directory structure. Is this how your backup archive is structured?
Also, I would like to see what errors might be occurring. Could you please direct message me the main.log file? On Mac you may locate this file by launching DevKinsta and selecting “Reveal log file” under the help menu in the top bar.
@Adrian_L
Tried another import and it didn’t work again despite, of course, now knowing exactly how to structure my export. Only change since last time (successful) was that Docker had an update. After that, I even quit DevKinsta and Docker and reopened and retried and still not working. Attached is the structure of my unzipped .zip
btw, the import that did work 2 days ago… I dug deeper and turns out it only imported 16 of the tables, not all of them. It didn’t have wp_posts, wp_postmeta, and many more that were in the SQL file but didn’t make it into the DB.
So I used the browser to import that same SQL file into that same DB and it resulted in many errors:
So I tried wp db import ... and got an error pointing to my wp-config.php
OMG, when I checked that, I see there was definitely an import error even though there weren’t any warnings or errors and the import completed. See my wp-config is just the local domain over and over:
Thanks for your reply, and for providing that error information. I’m sorry to see that you are now also having difficulty with importing the database using adminer. I know experiencing these errors can definitely be frustrating. We certainly want to ensure that we figure out the root cause of these issues, and get them resolved so you can successfully use DevKinsta for your site development.
It looks like the adminer issue might be related to a session issue. It appears that the session ID might not be getting set properly which could prevent the file upload. To see if this might be a local browser issue, please try clearing the cache and cookies of the browser that you use to view the adminer interface. You may also try opening the adminer interface in a private/incognito browser window.
If the issue persists, I would like to try fully re-creating the DevKinsta related Docker containers. To do this, please shut down DevKinsta fully and then once the DevKinsta related Docker containers have been stopped you may select them all in the Docker Desktop interface and choose to delete them. You may then relaunch DevKinsta which should automatically create the containers. After this, please try recreating the site using the .zip archive backup again, and/or reimporting the SQL file using adminer to see if that has resolved the errors you are seeing upon attempting to import the database backup.
I deleted containers in the past and turns out that lost my data - they didn’t just spin up with my same db, media, files, etc. - so I’d like exact steps what to do:
Thank you for your reply, and for providing those screenshots. Removing just the containers (not the volumes) should not result in data loss. The database data is stored in the devkinsta_db_data volume. That volume can continue to exist even after the containers are removed, and upon creation of the new containers those volumes can be used.
The containers should be stopped however before they are removed. DevKinsta upon being closed will continue to run in the background to make it quicker to start up in the future. To fully shutdown DevKinsta you may locate the DevKinsta icon in the top status bar, right click it, and then choose to quit DevKinsta. That will then allow you to fully shutdown the application.
Once DevKinsta has been shutdown you can confirm the containers have been stopped in the Docker Desktop dashboard. Once you have confirmed they are stopped you may select the DevKinsta related containers and choose to delete them. This again should only remove the containers while leaving the volumes and site files in place.
Upon launching DevKinsta the containers should be recreated. You may then attempt to import your backup again.
Please let us know if you need any assistance with these steps. Also, please do let us know if this has helped at all in regards to being able to import your .zip backup.
