Akeeba Backup for WordPress

Wednesday, 03 February 2016 23:49 CST

mlelao

Hi there!

I've been running in a new problem yesterday.

I made and downloaded a complete backup of the website just minutes before crashing it completely.
I erased everything from the server and the database before uploading the archive and kickstart.php.

And then, I get this message from Angie (whatever the option settings are; i've tried various combinations):

Database error processing line 0

Database server error reply:

ErrNo #0

SQL=CREATE TABLE `wp_ak_params` (`tag` varchar(255) NOT NULL ,`data` longtext NULL , PRIMARY KEY (`tag`)) ENGINE=InnoDB DEFAULT COLLATE utf8mb4_unicode_ci

Raw query text:

CREATE TABLE `#__ak_params` (`tag` varchar(255) NOT NULL ,`data` longtext NULL , PRIMARY KEY (`tag`)) ENGINE=InnoDB DEFAULT COLLATE utf8mb4_unicode_ci

Using phpMyAdmin, i tried the query directly and got the following message:

#1071 - Specified key was too long; max key length is 767 bytes

Considering the problem could be linked to the host, I tried to restore the website on another server: I get the exact same error.

I've seen in ticket #24358 that I'm not the only one to have same trouble... But I do not have the same means as Paul to regenerate a new backup, unfortunately.

Can you help me on this?

Thanks in advance!
m

PS: credentials to access the server are still the same (see ticket #24321)

Thursday, 04 February 2016 01:42 CST

nicholas

As I have explained, there is nothing we can help with. You need to make sure that your target MySQL server supports utf8mb4.

You CAN transfer FROM utf8 TO utf8mb4. You CANNOT transfer FROM utf8mb4 TO utf8. This is a MySQL limitation!

Even worse, even if you had your original site and you explicitly converted all tables to plain old utf8, WordPress would STILL upgrade ALL your tables to utf8mb4 WITHOUT asking you the next time it installs a core update.

If we allowed you to downgrade from utf8mb4 to utf8 you would get truncated data. The simple fact of life is that utf8mb4 can store up to 4 byte characters, utf8 can store up to 3 byte characters, if you try to save 4 byte characters to utf8 MySQL truncates the inserted data up to before the 4-byte character without warning and without throwing an error! Therefore if we allow you to do that you WILL get a corrupt site.

The only possible course of action is buying hosting on a host with a utf8mb4-capable MySQL database server.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Thursday, 04 February 2016 02:11 CST

mlelao

Hi Nicholas!

I think I didn't make things clear enough...

The site was up and running on the very same servers using the exact same configuration. I crashed it while trying to solve a problem with the plug-ins I use to manage translations (CMS multilingual, provided by wpml.org).

Since I knew beforehand there was a risk to crash the website, I made backup and downloaded the jpa archive; then I started to tweak the DB and plug-ins, which resulted in the crashed website.

After the crash, I cleaned both the DB and the website files, planning to restart one step before the crash thanks to the jpa archive. Unfortunately, I get this error –described in my first message– while I try to reinstall the database on the same mysql server.

Whatever, if you confirm you cannot do anything to help, I can still understand it ;-)

Best
m

Edited by mlelao on 2016-02-04 02:22 CST

Thursday, 04 February 2016 02:42 CST

nicholas

OK, if it's on the same server try unchecking the Detect utf8mb4 option in the restoration script, in the database setup page. Apparently one of your tables is still in utf8 format because of its key size. Trying to upgrade it to utf8mb4 causes an error.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Thursday, 04 February 2016 11:11 CST

mlelao

I tried this also, and it didn't work.

I've restarted from the ground up, taking the last backup archive from the development server and reinstalled everything.
I took the time to check at each step that each table of the DB had the proper collation.

Now everything works fine!

Once more, thanks for the kind support!
m

Support