Kategorien

#301 Akeeba Backup restore fails because of EasyBlog database collation

Veröffentlicht in ‘EasyBlog’

Ticket schließen Ticket bearbeiten

Öffentlich

Ausstehend

Dies ist ein öffentliches Ticket

Jeder kann den Inhalt sehen. Geben Sie keine Benutzernamen, Passwörter oder andere sensible Informationen ein.

Letzter Beitrag von CreativeGraphics Support am Sonntag, 26. Juli 2026 13:52 UTC

Samstag, 27. Juni 2026 10:32 UTC

EdCentral

Hi,

I found what appears to be a compatibility issue while restoring an Akeeba Backup created from a Joomla site using CRE8 Blog.

Environment

Joomla: 6.1.1
CRE8 Blog version: 7.1.0
Akeeba Backup Core: 10.3.3
Production server: MariaDB 11.4.x
Local development: MySQL 8 (Laravel Herd)

During the database restoration in ANGIE (Akeeba Backup), the restore stops with:

ErrNo #1273
Unknown collation: 'utf8mb4_uca1400_ai_ci'

The first failing statement is:

CREATE TABLE `#__easyblog_optimizer` (
...
) ENGINE=InnoDB
DEFAULT CHARSET=utf8mb4
COLLATE=utf8mb4_uca1400_ai_ci;

I enabled all available Akeeba options:

Normalise character set
Force UTF-8 collation on database
Force UTF-8 collation on tables
Allow UTF8MB4 auto-detection

The restore still fails.

As a test, I excluded all CRE8 EasyBlog tables (__easyblog) from the restoration, and the remaining Joomla database restored successfully.

Could you please check whether the extension is explicitly creating tables with the MariaDB-specific collation utf8mb4_uca1400_ai_ci?

Bearbeiten

Sonntag, 26. Juli 2026 13:52 UTC

CreativeGraphics Support

Dear Louise

Please excuse my delay in replying to your request.

No, CRE8 Blog doesn't hardcode utf8mb4_uca1400_ai_ci anywhere. I checked all 13 install SQL files (queries/*.sql) and every single CREATE TABLE only specifies DEFAULT CHARSET=utf8mb4 — none of them pins an explicit COLLATE.

MariaDB 11.4.2+ changed its server-wide default collation for utf8mb4 from the old utf8mb4_general_ci/utf8mb4_unicode_ci to a new one, utf8mb4_uca1400_ai_ci (MariaDB docs https://mariadb.com/docs/server/reference/data-types/string-data-types/character-sets/setting-character-sets-and-collations), MDEV-25829 (https://jira.mariadb.org/browse/MDEV-25829).

Since EasyBlog's CREATE TABLE statements never specify a COLLATE, MariaDB silently fills in whatever the server's current default is. On your production server (MariaDB 11.4.x) that's utf8mb4_uca1400_ai_ci — a MariaDB-only collation that has no equivalent in MySQL.

Akeeba's backup captures the table structure as it actually exists in the live DB (not from our install SQL), so the dump correctly reflects that inherited collation. When ANGIE tries to replay that CREATE TABLE against MySQL 8 (Laravel Herd locally), MySQL has never heard of utf8mb4_uca1400_ai_ci → Unknown collation fatal, and the whole restore aborts on the first #__easyblog_* table it hits.

This explains why all #__easyblog_* tables failed, not just optimizer — it's a schema-wide gap, and optimizer just happens to be the first one alphabetically/in dump order.

You have the following options:

Upgrade your local MySQL 8 dev environment to MariaDB to match production
Pre-create the #__easyblog_* tables manually with a compatible collation before running the restore
Retry to use Akeeba/ANGIE's "Fordce UTF8MB4 collation" option, as it normally rewrites unknown collations during restore

Retrofitting a COLLATE across every table in the schema risks collation-mismatch errors (Illegal mix of collations in joins with Joomla core, or friction on ALTER/upgrade paths for existing installs) for the entire customer base and is therefore not an option.

Best regards, Pascal

Bearbeiten