Import from Kinsta gives blank wordpress install 2

Same issue as: Import from Kinsta gives blank wordpress install (but can’t see any way to reopen, so creating new topic with same name)

Running:

  • Latest DevKinsta 2.5.0.3657
  • Windows 10 Pro
  • Latest Docker Desktop/Engine 4.8.1

Steps to recreate issue:

  • Brand new Wordpress install to Kinsta account
  • Connect DevKinsta to KinstaAccount
  • Add site → Import from Kinsta

Outcome: Causes blank wordpress install.

(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.

1 Like

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.

Hey Kevin, thanks for the ultra quick response!

Sounds good. I look forward to the update.

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.

Thanks again!

1 Like

Yes, so DevKinsta looks for backup.sql in ~/public after the file transfer and uses that to populate the local database.

As long as there is a backup.sql in ~/public on the source/Kinsta site, DevKinsta will use that after you Pull in the site.

So basically just rename that file, move it, then Pull from Kinsta to DevKinsta and it should work as expected!

So basically, I will need to pull the site, let it fail, rename the file to “backup.sql”, move it to the ~/public folder and then pull the site again?

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.

Ok understood. Much appreciated!

However, 2 quick questions:

  1. 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).
  2. 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?!

You’re welcome!

  1. Yes that is correct; you’ll just have to try the process to get a handle on what’s going on.
  2. 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.

Hi @dgilfillan, version 2.6.0 of DevKinsta has just been released. Please retry with this version and let me know if the issue persists.

Hi Kevin, using the new version (v2.6.0.4179) I can confirm importing is working correctly. Many thanks for your efforts!

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.