V3.2.15

Clone Master 3.2.15

Cette version améliore la fiabilité des restaurations volumineuses et corrige deux erreurs pouvant interrompre une importation avant la mise en production des données.

Compatibilité complète avec les noms de tables MySQL longs

Clone Master utilise des tables temporaires de staging afin de préparer et de valider une restauration sans modifier immédiatement les tables existantes.

Dans certains cas, le préfixe de staging ajouté au nom d’origine pouvait produire un identifiant dépassant la limite MySQL de 64 caractères. Ce problème concernait notamment certaines tables créées par des extensions utilisant des noms particulièrement longs.

La version 3.2.15 intègre le correctif introduit avec la version 3.2.14 :

• génération automatique d’un alias temporaire lorsque le nom dépasse la limite MySQL ;
• conservation exacte du nom final d’origine ;
• correspondance déterministe entre les tables sources, temporaires et finales ;
• détection des éventuelles collisions de noms ;
• utilisation cohérente du mappage pendant l’importation, la validation, le remplacement des URL et la promotion finale des tables.

Cette correction évite notamment l’erreur MySQL suivante :

SQL staging failed [1103]: Incorrect table name

Correction du remplacement d’URL avec les emojis et l’Unicode

Le remplacement des anciennes URL pouvait échouer lorsqu’une valeur contenait un emoji ou un caractère Unicode nécessitant quatre octets.

L’import SQL pouvait correctement charger ces données en utf8mb4, puis une connexion ultérieure utilisée pendant le remplacement des URL pouvait être rouverte avec un jeu de caractères plus limité, généralement utf8.

MySQL refusait alors la réécriture de valeurs pourtant déjà présentes dans la table, avec une erreur similaire à celle-ci :

Incorrect string value: '\xF0\x9F\x91\x89...'

Clone Master utilise désormais une connexion compatible utf8mb4 pendant les opérations de migration et de remplacement d’URL.

Cette correction permet de conserver correctement :

• les emojis ;
• les caractères Unicode sur quatre octets ;
• les contenus provenant des métadonnées WordPress ;
• les blocs Gutenberg ;
• les données sérialisées ;
• les contenus multilingues ;
• les textes enregistrés par des extensions tierces.

Le charset et la collation des tables existantes ne sont pas modifiés automatiquement.

Diagnostics enrichis

Les messages de diagnostic du remplacement d’URL incluent désormais davantage d’informations techniques lorsque MySQL refuse une valeur :

• table concernée ;
• colonne concernée ;
• charset de la colonne ;
• collation de la colonne ;
• charset actif de la connexion ;
• identifiant du diagnostic.

Ces informations facilitent l’analyse des bases anciennes, hétérogènes ou partiellement converties vers utf8mb4.

Fiabilité de la restauration transactionnelle

Les correctifs sont appliqués pendant la phase de staging, avant la promotion finale des données.

En cas d’erreur :

• les tables existantes restent intactes ;
• les fichiers existants ne sont pas remplacés ;
• la restauration peut être relancée après correction ;
• les contrôles de schéma et de nombre de lignes restent actifs ;
• la promotion finale conserve son fonctionnement atomique.

Résumé des corrections

• correction des noms de tables temporaires dépassant 64 caractères ;
• prise en charge des tables d’extensions possédant des noms très longs ;
• connexion de migration forcée en utf8mb4 ;
• correction du remplacement d’URL dans les valeurs contenant des emojis ;
• conservation du charset et de la collation des tables ;
• amélioration des diagnostics SQL ;
• renforcement du mappage entre les tables de staging et les tables finales ;
• validation de la compatibilité avec les métadonnées WordPress ;
• validation de l’intégrité de l’archive générée.

La mise à jour vers Clone Master 3.2.15 est recommandée pour toutes les restaurations, migrations ou importations de sauvegardes volumineuses.