Support

The new server does not support the utf8mb4_0900_ai_ci collation. This collation was added to MySQL 8.0.

If your new host is running a MySQL version earlier than 8.0 they need to update it; older versions are no longer developed or supported.

If they are using MariaDB please let me know. MariaDB has unfortunately not added support for this collation, therefore we'll have to work around it. Before we start doing that, I need to make sure this is the case.

Okay, now it all makes sense. MariaDB is a weird combination, where its version is higher than MySQL's, but does not implement the same features.

First, extract your backup archive using Kickstart.

AFTER extracting the backup archive and BEFORE clicking on the button to run the installer extract the following files to your site:

• https://www.dropbox.com/scl/fi/tuyq41k3udeoyqum8eib9/angie.zip?rlkey=haetbh6vh3jyczr80pe61x1em&dl=0  
• https://www.dropbox.com/scl/fi/yf8yzpzah783p9cvib7nd/angie-joomla.zip?rlkey=grixqtj348j3g7uawfraycky8&dl=0 

These replace files in the installation directory where the restoration script (ANGIE) was extracted to.

Now you can proceed with the rest of the installation.

Correct.

The actual problem, so that you know, is that your database server lies about its type and version.

The Akeeba Backup restoration script (ANGIE) has had code to convert the utf8mb4_0900_ai_ci collation to utf8mb4_unicode_520_ci when it detects a database server version lower than 8.0. This code has been there since Akeeba Backup 7.2.2 (released July 13th, 2020). It's the changelog entry “Automatic UTF8MB4 character encoding downgrades from MySQL 8 to 5.7/5.6/5.5 on restoration”.

This all worked on MariaDB, because MariaDB reported its version with the prefix 5.5.5-MariaDB. Since the detected version in this case is 5.5.5, which is lower than 8.0, the aforementioned code kicked in and converted the collation.

At some point, I believe around MariaDB 10.4, MariaDB stopped reporting its version in this way. Now it reports it as something like 10.4.32-MariaDB-…. The detected version is 10.x which is higher than 8.x, therefore the code does not apply anymore. Why this only became an issue with MariaDB now is pretty simple. MariaDB 10.3 (the previous Long Term Support version) became End of Life a couple of months ago, therefore hosts started upgrading to newer versions of MariaDB.

The changes I made in the files I sent you specifically check for the MariaDB string in the server version. When they detect it, they immediately apply the “this is not MySQL 8 or later” code I mentioned above, changing the collation. I confirmed it by running MariaDB 10.4 on Docker, doing a restoration there. I can see that the collation of the tables and columns which was set to utf8mb4_0900_ai_ci on the original server are not converted to utf8mb4_unicode_520_ci as they should.

The fact that your server does not work with that tells me that either you didn't extract the files after extracting the backup archive (which means that my changes got overridden by the older code in your backup archive) OR your server reports a misleading database server version. Since you've asked me explicitly if you are to extract both file I assume it's not the former, therefore it can only be the latter.

If by any chance you made a mistake, extracting the files I sent you before extracting the backup archive, there's your problem.

As a final note: this issue will be fixed in a new release of Akeeba Backup 9 for Joomla! 4 and 5, but not in Akeeba Backup 8 which as we have already stated is out of regular support. We won't make bug fix releases to Akeeba Backup 8, only security releases.

If you have a Joomla! 3 backup affected by this issue, there's a simple workaround. After extracting the backup archive and BEFORE clicking on Run the Installer button edit the file installation/framework/database/restore/mysqli.php and change the line

static $MySQL8 = null;

to

static $MySQL8 = false;

This will fix the problem with the collation.