Support

You should probably use:

utf8tables: false
charset_conversion: false

The charset_conversion tries to translate character sets to what is the default representation of that character set in your database server. The original charset of the column was utf8mb3 which translates to utf8 because of charset_conversion.

Using utf8tables means that you want the table, and all its text columns, to be converted to a utf8mb4_* collation. This changes the column's collation to utf8mb4_unicode_ci.

However, this is an illegal combination. Hence the problem.

You can probably use charset_conversion by itself, but not together with charset_conversion in this case. Ideally, the extension should not be using a mix of character sets like that. They should either have the entire table use UTF8(MB3) or UTF8MB4. The latter is a superset of the former. There is also no point in setting both charset and collation. If they need to specify the collation they should specify the collation only; it implies the charset in a deterministic manner.

The CLI installer is not a different application; it's the same application. Instead of having a web interface it has a CLI interface. The actual restoration code (the Model in the Model-View-Contoller) is the same in both cases. The configuration you provide is consumed the same way.

I think that the problem is ultimately some mistake made in the original site. Having the character set and collation set on the table and each column is weird. Having the character set of one specific column be UTF8 3-byte when everywhere else is 4-byte is also very weird. Can you please check with the extension developer that this is really what they are doing? If not, the problem must've come from some issue during the maintenance of the site. Changing the one column's charset and collation from utf8mb3 to utf8mb4 and taking a new backup would fix that problem.

We cannot include a SQL lexer and parser to address the situation where a column has both a charset and a collation. The SQL lexers written in PHP are very iffy; SQL is very similar to COBOL and has a very loose syntax. If the lexer doesn't fail completely, the parser would have a hard time determining the constituent information of the column definition since the lexer tree could be any number of weird shapes (SQL's loose syntax means that a number of possible combination of options can create wildly different tree shapes).

I might be able to come up with a way to address situations like these without a lexer and parser, but I really can't promise that.

I am having a really hard time reproducing your issue in the way you have written it down.

When the column definition is:

`trigger` varchar(100) CHARACTER SET utf8mb3 COLLATE utf8mb3_general_ci NOT NULL,

then the MySQL I get is

`trigger` varchar(100) CHARACTER SET utf8mb3 COLLATE utf8mb4_general_ci NOT NULL,

The only way where I can get the exact error message you provided is if the original table has the definition:

`trigger` varchar(100) CHARACTER SET utf8 COLLATE utf8mb3_general_ci NOT NULL,

in which case the resulting MySQL is indeed

`trigger` varchar(100) CHARACTER SET utf8 COLLATE utf8mb4_general_ci NOT NULL,

Are you absolutely sure that the CREATE and error message SQL you sent me are copied verbatim?

OK, that explains it. The column character set is defined as utf8, and mysqldump converts it to utf8mb3 to disambiguate (since the collation is utf8mb3_general_ci).

The database dump we are working on, however, is read verbatim from MySQL which returns the exact character set used for the column definition. That's just utf8.

Yes, with these conditions I can both reproduce and solve the issue you have.

Please try installing https://www.akeeba.com/download/akeebabackuppro-dev/10-0-3-dev202503032002-revcf6191d.html and taking a new backup. Restoring that backup –using the options you were previously using– will now work.

Thank you for the feedback! I'll release a new version next week.