Import .zip downloaded from Flywheel 'not compatible'

Support
1

What issue or error are you experiencing?

Obtained an export of a site through Flywheel in May. Trying to load the zip file in Local now. Each time it says the zip file is not compatible and cancels the process.
local-logs.zip (1.5 MB)

What steps can be taken to replicate the issue? Feel free to include screenshots, videos, etc

I suppose you’d need the same zip file I have, but the file size is too big to upload here.

System Details

  • Local Version:
    Version 9.0.5+6706
  • Operating System (OS) and OS version:
    Mac Sonoma 14.6.1

Local Logs

Attach your Local Logs here (Help Doc - Retrieving Local’s Log)

Security Reminder
Local does a pretty good job of scrubbing private info from the logs and the errors it produces, however there’s always the possibility that something private can come through. Because these are public forums, always review the screenshots you are sharing to make sure there isn’t private info like passwords being displayed.

2

Hi @DavidG

There could be a few reasons why it’s being marked as incompatible. One thing you can try and do is open up the zip file and whittle it down to just the necessary WP-Content and SQL files. If there are any extra site backups, DB backups, media backups, etc those should be removed as they can sometimes conflict with the native import process.

If you’re still not having any luck you can always use our steps for manually importing a site here:

Manually Import a Local Site

3

Thanks @Nick-B !

There were some files in the zip that were causing an issue. But that wasn’t the only issue.

Even after creating a new zip with the rogue files removed, the import failed. I’d get this error:

ERROR 2006 (HY000) at line 915 in file: ‘backup.sql’: MySQL server has gone away (with wp cli)
Error in query (2006): MySQL server has gone away (with Adminer)

This was due to the db being so large (92.6MB).

To fix this I had to run these commands individually in Adminer:

SET GLOBAL max_allowed_packet=268435456;
SET GLOBAL wait_timeout=300;
SET GLOBAL interactive_timeout=300;

After doing that, I got an import success message both when using wp cli and Adminer. However, the db wasn’t actually imported. It was still the default db created when creating the blank site in Local.

I have no idea why both import methods resulted in a success message but nothing was actually imported.

So I had to run: ‘wp db reset --yes’ to wipe out the db. Of course, after doing this it also wiped the globals, so I had to individually re-run those three SET GLOBAL commands.

I was then able to import backup.sql in Adminer and see the data I was expecting. I didn’t try it with wp cli but assume that would have worked too after the reset.

Next, I tried to do a search/replace to update the URL but got this error:

Error: The site you have requested is not installed. Your table prefix is ‘wp_’. Found installation with table prefix: wpXXXXXXXX .

So I had to edit the wp-config.php line:

$table_prefix = ‘wp_’;

… to match the imported db’s table prefix.

Then I was able to do a search and replace and the site loaded fine in Local. Yay!

4

92.6MB doesn’t seem that large for a DB import unless it has some bloated tables with lots of rows or something like that may have been causing a timeout maybe?

Regardless, thank you for sharing all of your work here @DavidG!