After import: Your wp-config.php file has an empty database table prefix, which is not supported

I’ve imported a site into Local with a zip of mydatabase.sql and /wp-content. It created a site in Local, but when I go to site.dev, I get the message:

Your wp-config.php file has an empty database table prefix, which is not supported.

I followed the suggestion to add the table prefix here: ERR_CONNECTION_REFUSED - not finding a solution - #11 by clay - Support - Local Community.

When I go into Adminer and inspect the Local database, I see the database has not been imported at all.

I tried changing $table_prefix = ‘’; to $table_prefix = ‘wp_’; and then accessing site.dev leads me to the WP installer.

I also tried importing the mydatabase.sql via Adminer, and got:

Error in query (1273): Unknown collation: ‘utf8mb4_unicode_520_ci’. The file mydatabase.sql was created with WP-CLI wp db export.

Secondary question: Why does this import process discourage the use of the original site’s wp-config.php file?

Hi David,

Can you try re-importing the site but use MySQL 5.6 instead of MySQL 5.5?

Also it does use the wp-config.php from the archive if it exists. It just has to edit a few of the constants as well as $table_prefix.

My guess is that it’s failing to import on MySQL 5.5 due to the lack of utf8mb4 support. Since it can’t import, it’s then unable to get the MySQL database prefix.

Using MySQL 5.6 should help the import succeed which should correct the wp-config.php settings.

I appreciate the help, Clay. That fixed it!

I’ve got to say, creating a site from a zip like that with drag and drop is pretty slick. I wish site migration was always that easy!

1 Like

Hey, Clay, this didn’t work for me, I am still getting the same issue. :frowning:

Hi David,

Please click on the “Database” tab for the imported site and then open Adminer or Sequel Pro. Then, make a note of the table prefix you see. It’ll be something like wp_ in front of all of your tables.

Once you have the prefix, open wp-config.php in app/public and adjust the $table_prefix variable accordingly.

We’re working on hardening the table prefix detection in an upcoming update.

Sorry for the trouble!

This is all that I see, Clay, I don’t think something is right here: