Support

 Hi,

I don't think this is a problem, but just want to make sure.

I selected UTF-8 Joomla! default to change the collation of an existing Joomla database from the mysql default latin1_swedish_ci.

I was expecting utf8_general_ci but got utf8mb4_unicode_ci.

I read about utf8mb4_unicode_ci and understand that it supports 4-byte encoding rather than utf8_general_ci 3-byte encoding.

I'm assuming this is a good thing, but the Joomla tables themselves that were already in the database were reported as utf8_general_ci. Can I assume that utf8mb4_unicode_ci collation for the database is fine? I'm thinking the difference is just version related since I did a test collation change on a system that uses PHP 5.5.21 and MySQL 5.5.44.

Thanks!

Kind regards,
reddeer

https://dev.mysql.com/doc/refman/5.5/en/charset-unicode-utf8mb4.html confirms utf8mb4 corresponds to newer MySQL.

I've been reading about issues when changing from 3-byte to 4-byte encoding, but am hoping they won't be a problem.

Thanks again.

Reddeer,

That's a good thing as long as your MySQL installation supports it. If you were developing on a MySQL server with MB support and the live server didn't support it, you would need to change the local settings. As long as this is the final destination of the site or all of the servers involved support it, you're fine.

Hi Dale,

Thank you for the reply.

Since the dev.mysql.com documentation says "As of MySQL 5.5.3, the utf8mb4 character set uses a maximum of four bytes per character supports supplemental characters." then I should be able to do an Akeeba backup of the production (MySQL 5.6.28) site and restore it to the test VM (MySQL 5.5.44), right?

I'm confused because although both systems are using MySQL versions later than 5.5.3, during the Admin Tools collation change, one site defaulted to utf8mb4_unicode_ci and the other defaulted to utf8mb4_unicode_ci. Since one site is a clone of the other, I would have expected the collation change to result in the same new collation type. I am just wondering whether the difference in collation change results implies that there is lack of support for utf8mb4_unicode_ci on the test system.

Thanks, again.

Kind regards,
reddeer

Thank you for the detailed explanation. Ideally IT will implement mb4 support on the local test VM.

However, just in case mb4 support is not implemented and I am left with no choice but to use the system that does not support mb4, is it possible/safe using Admin Tools to change the database collation type to 3-byte utf8 on the production system that does support mb4 before cloning the site to the non-mb4 system ? (I realize changing from 4-byte to 3-byte is not desirable from a technical standpoint.)

Thank you again.

I was able to have mb4 enabled on the test system.

I then ran Admin Tools database collation change to change the collation to utf8mb4_unicode_ci.

Database collation type was successfully changed to utf8mb4_unicode_ci.
Connection collation type was changed to utf8mb4_unicode_ci.

Is this normal for the connection type to become unicode while the database is changed to general?

Thanks.

I suspect that when mb4 was enabled on the test VM, there must have been someplace where the corresponding connection collation type could be set and perhaps the admin used unicode instead of general. I say this because I double-checked the production system and the connection type appears to have been automatically changed to utfmb4_general_ci at the same time Admin Tools applied the collation change to the database.

Fortunately it's possible in phpMyAdmin to rest the connection collation, so I was able to do that manually.

I think we can call this issue solved.

Thanks again for both Admin Tools and Akeeba Backup!