V3.1.6
Clone Master V3.1.6
Clone Master V3.1.6 marque une étape importante dans la fiabilisation du moteur de sauvegarde, de migration et de restauration WordPress.
Cette version ne se limite pas à corriger quelques erreurs visibles. Elle renforce les mécanismes les plus sensibles du plugin : validation des archives, restauration transactionnelle, remplacement des URL, gestion des données sérialisées, reprise après interruption et compatibilité avec des environnements d’hébergement réels.
Points forts de la version 3.1.6
- restauration complète validée sur une archive de plus de 200 Mo ;
- prise en charge de près de 20 000 fichiers pendant une migration réelle ;
- validation de dizaines de tables WordPress et de tables personnalisées ;
- remplacement sécurisé des URL dans les textes et les données sérialisées ;
- meilleure compatibilité avec les contenus tronqués ou ressemblant à des données sérialisées ;
- rollback automatique renforcé ;
- reprise fiable après une coupure ou une restauration interrompue ;
- amélioration des diagnostics ;
- noms de sauvegarde commençant désormais par le domaine du site ;
- compatibilité testée avec PHP 8.5, nginx et LiteSpeed Web Server.
Un moteur de sauvegarde plus rigoureux qu’un simple ZIP
Clone Master utilise son propre format d’archive .wpcm.
Contrairement à une sauvegarde classique composée d’un ZIP et d’un dump SQL, le format .wpcm repose sur une architecture pensée pour la vérification, la reprise et la restauration sécurisée.
Format append-only
Les blocs de données sont ajoutés progressivement à l’archive sans réécrire continuellement les parties déjà validées.
Cette méthode réduit le risque qu’une interruption pendant la création de la sauvegarde rende l’ensemble de l’archive inutilisable.
Vérification SHA-256
Chaque bloc de l’archive est associé à une empreinte SHA-256.
Lors de l’envoi, de l’extraction et de la restauration, Clone Master vérifie que chaque bloc correspond exactement à l’empreinte attendue.
Un bloc incomplet, modifié ou corrompu est détecté avant que le site actif ne soit remplacé.
Reprise au dernier bloc validé
Les grandes archives sont envoyées en plusieurs morceaux.
En cas de coupure réseau, l’envoi peut reprendre à partir du dernier bloc validé au lieu de recommencer depuis le début.
Cette amélioration est particulièrement utile pour les sauvegardes de plusieurs centaines de mégaoctets.
Restauration transactionnelle
La restauration est maintenant entièrement préparée avant la bascule finale.
Clone Master suit notamment les étapes suivantes :
- validation complète de l’archive
.wpcm; - extraction atomique dans un emplacement temporaire ;
- création des tables de staging ;
- import de la base de données dans les tables temporaires ;
- validation du nombre de lignes ;
- validation des schémas SQL ;
- remplacement des URL et chemins ;
- validation des fichiers préparés ;
- bascule des tables et des fichiers ;
- contrôle du site restauré ;
- rollback automatique en cas d’échec.
Les fichiers et tables existants restent en place tant que les contrôles de préparation ne sont pas terminés.
Journal de restauration protégé
Le moteur utilise un journal de restauration protégé par HMAC.
Ce journal est enregistré sur deux emplacements alternés afin de limiter le risque de perdre l’état de la restauration si le serveur s’arrête au moment où le journal est lui-même en cours d’écriture.
Clone Master peut ainsi déterminer plus précisément :
- la dernière étape terminée ;
- les tables déjà préparées ;
- les fichiers déjà basculés ;
- l’état précédent encore disponible ;
- l’action de récupération ou de rollback à effectuer.
Rollback automatique corrigé
Une erreur pouvait survenir lorsqu’une restauration interrompue était détectée très tôt pendant le chargement de WordPress :
Call to undefined function wp_salt()
La récupération pouvait être exécutée avant le chargement des fonctions WordPress dites pluggable.
Clone Master 3.1.6 ne dépend plus directement de wp_salt() pendant cette phase précoce.
Le moteur peut désormais dériver les informations nécessaires à partir des constantes disponibles dans wp-config.php, puis utiliser les fonctions WordPress normales lorsqu’elles sont chargées.
Remplacement des URL inspiré de la méthode WP-CLI
Le remplacement des URL a été profondément renforcé.
WordPress et de nombreuses extensions stockent des tableaux et objets sous forme sérialisée.
Exemple :
s:24:"https://ancien-site.fr";
Le nombre 24 correspond à la longueur exacte de la chaîne.
Un remplacement SQL classique peut modifier l’adresse sans recalculer cette longueur, ce qui rend ensuite la valeur illisible.
Clone Master analyse les structures sérialisées, remplace les URL récursivement et recalcule les longueurs en octets.
Correction des faux positifs
Certaines colonnes peuvent contenir un texte qui commence comme une valeur sérialisée sans être une structure complète.
Cela peut arriver dans :
- des extraits ;
- des journaux ;
- des caches ;
- des contenus tronqués ;
- certaines tables d’extensions.
Les versions précédentes pouvaient considérer ces valeurs comme des données sérialisées corrompues et interrompre la migration avec :
A serialized length field is incomplete.
La version 3.1.6 applique désormais une logique proche de celle utilisée par WP-CLI :
- la valeur complète est analysée ;
- si la structure est entièrement valide, elle est traitée comme une donnée sérialisée ;
- si l’analyse complète échoue, la valeur est traitée comme un texte ordinaire ;
- aucun objet PHP provenant de l’archive n’est instancié.
Cette correction permet notamment de traiter correctement les colonnes d’extrait de certaines extensions.
Prise en charge des objets sérialisés
Le moteur prend maintenant en charge :
- les tableaux sérialisés ;
- les objets sérialisés standards ;
- les objets personnalisés ;
- les structures imbriquées ;
- les chaînes contenant des caractères multioctets ;
- les valeurs contenant des URL encodées.
Les classes PHP ne sont jamais instanciées pendant la migration.
Le remplacement est effectué directement dans la représentation sérialisée, avec recalcul des longueurs.
Conservation exacte du caractère %
Clone Master protège désormais explicitement les valeurs WordPress contenant %.
Exemples :
/%postname%/
%%title%%
58%
https://example.com/fichier%20avec%20espace
Le moteur ne réalise jamais de remplacement global du caractère %.
Les structures de permaliens, modèles SEO, pourcentages et URL encodées sont conservés exactement.
Clone Master vérifie également qu’aucun placeholder temporaire non restauré ne soit enregistré dans la base.
Validation renforcée des schémas SQL
La validation des tables a été améliorée pour gérer les différences légitimes produites pendant le staging.
Normalisation des préfixes temporaires
Pendant la préparation, les tables sont renommées avec un préfixe temporaire du type :
wpcmstg_xxxxxxxxxx_
MariaDB peut reprendre ce préfixe dans :
- les clés étrangères ;
- les contraintes ;
- les références de tables ;
- certains éléments de la définition SQL.
Clone Master calcule désormais un hash canonique après normalisation du préfixe temporaire.
Lorsque :
canonical_hash = expected_hash
la structure est considérée comme valide.
L’événement suivant peut apparaître dans les diagnostics :
installer_schema_prefix_normalized
Ce message signifie que la structure a été validée après normalisation. Il ne signale pas une corruption.
Normalisation de AUTO_INCREMENT
Sur une table active, la valeur AUTO_INCREMENT peut évoluer pendant la sauvegarde.
Une comparaison brute peut alors signaler une différence alors que la structure réelle de la table n’a pas changé.
Clone Master normalise maintenant cette valeur avant la comparaison des schémas.
Réécriture SQL plus précise
L’ancien moteur pouvait remplacer trop largement certains identifiants SQL contenant le préfixe WordPress.
La nouvelle méthode réécrit uniquement les éléments nécessaires :
- les tables ciblées par
CREATE TABLE; - les tables ciblées par
DROP TABLE; - les tables ciblées par
INSERT INTO; - les références de clés étrangères ;
- les symboles de contraintes susceptibles d’entrer en collision.
Les noms de colonnes et d’index ne sont plus modifiés uniquement parce qu’ils commencent par le préfixe WordPress.
Cette correction évite notamment les différences de schéma sur les tables personnalisées.
Pagination MySQL améliorée
Le parcours des grandes tables a été renforcé afin d’éviter les ralentissements progressifs liés aux grands décalages SQL.
Une pagination basée uniquement sur LIMIT ... OFFSET ... peut devenir de plus en plus coûteuse à mesure que l’export avance.
Clone Master utilise des curseurs plus stables pour éviter de reparcourir continuellement les lignes déjà traitées.
Cette amélioration réduit les risques de :
- timeout ;
- forte consommation CPU ;
- export qui ralentit vers la fin ;
- comportement quadratique sur les grosses tables.
Compatibilité avec les hébergements réels
Clone Master a été durci contre plusieurs particularités rencontrées sur des serveurs WordPress réels.
Environnements testés
- PHP 8.5 ;
- nginx ;
- LiteSpeed Web Server ;
- MySQL ;
- MariaDB ;
- WordPress avec tables personnalisées ;
- archives de plus de 200 Mo ;
- sites contenant près de 20 000 fichiers ;
- données sérialisées complexes ;
- caches serveur agressifs.
Cache HTTP serveur
Certains serveurs peuvent intercepter une requête avant même que PHP et WordPress ne soient exécutés.
Cela peut donner l’impression d’un bug dans l’interface ou dans les réponses AJAX alors que le plugin n’a jamais reçu la requête.
Clone Master améliore désormais ses identifiants de requête, ses diagnostics et ses réponses afin de faciliter l’identification de ce type de problème.
WordPress loopback et WP-Cron
Certains hébergements bloquent les requêtes internes de WordPress ou désactivent WP-Cron.
Le moteur évite de dépendre entièrement de ces mécanismes pour les opérations critiques de restauration.
Noms de sauvegarde améliorés
Les nouvelles sauvegardes commencent désormais par le domaine du site.
Exemple pour une sauvegarde manuelle :
monsite.fr-backup-manual-20260725T183500-a1b2c3d4e5f6.wpcm
Exemple pour une sauvegarde automatique :
monsite.fr-backup-auto-20260725T183500-a1b2c3d4e5f6.wpcm
Le préfixe www. est retiré automatiquement.
Les domaines internationalisés sont normalisés lorsqu’une conversion est disponible.
Cette convention facilite la gestion de sauvegardes provenant de plusieurs sites.
Sauvegardes automatiques et rétention
La rétention automatique identifie maintenant les sauvegardes grâce au marqueur :
domain-backup-auto
Les sauvegardes manuelles ne sont jamais supprimées par la politique de rétention automatique.
La compatibilité avec l’ancien format de nommage auto_*.wpcm est conservée.
Interface et diagnostics
Plusieurs améliorations ont été apportées à l’interface React :
- ajout de limites d’erreur pour éviter la disparition complète de l’interface ;
- correction d’une erreur JavaScript dans le panneau de diagnostic ;
- meilleur affichage des erreurs par section ;
- journal d’activité plus précis ;
- identifiants de diagnostic uniques ;
- suivi de la mémoire utilisée ;
- affichage de l’étape concernée ;
- meilleure distinction entre informations, avertissements et erreurs ;
- traductions françaises mises à jour.
Contenu du diagnostic
Les rapports peuvent notamment contenir :
- la version du plugin ;
- la version de WordPress ;
- la version de PHP ;
- le serveur web ;
- la version de la base de données ;
- la limite mémoire ;
- l’étape de restauration ;
- la requête concernée ;
- le pic mémoire ;
- le fichier et la ligne ;
- un identifiant
diag_....
Exemple :
diag_20260725190817_5a11f91e3a
Cet identifiant permet de retrouver précisément un événement dans le journal.
Validation réalisée
La version 3.1.6 a été testée sur une migration complète comprenant notamment :
- une archive de 216 361 749 octets ;
- 52 morceaux envoyés ;
- 67 tables dans le manifeste ;
- 19 548 fichiers ;
- validation des schémas ;
- validation des nombres de lignes ;
- remplacement des URL ;
- traitement des données sérialisées ;
- préparation des fichiers ;
- bascule finale ;
- finalisation à 100 %.
La migration a été menée jusqu’à son terme avec succès.
Tests automatiques ajoutés
Les tests couvrent notamment :
- la syntaxe PHP ;
- la syntaxe JavaScript ;
- le format
.wpcm; - la reprise des blocs ;
- les archives WPCMARCHIVE2 ;
- les données sérialisées ;
- les objets sérialisés ;
- les extraits ressemblant à des données sérialisées ;
- les structures tronquées ;
- les caractères
%; - les URL encodées ;
- la normalisation des schémas ;
- les compteurs
AUTO_INCREMENT; - les préfixes de staging ;
- le bootstrap de récupération sans
wp_salt(); - les curseurs de pagination ;
- les identifiants de requête ;
- la cohérence transactionnelle ;
- l’intégrité du paquet final.
Mise à jour
La mise à jour peut être installée directement par-dessus une version précédente de Clone Master.
Les archives .wpcm déjà créées restent compatibles.
Après la mise à jour :
- remplacez l’ancienne version du plugin ;
- activez Clone Master 3.1.6 ;
- ouvrez l’administration WordPress ;
- vérifiez la page des diagnostics ;
- lancez une nouvelle sauvegarde de contrôle ;
- conservez l’ancienne sauvegarde jusqu’à validation de la nouvelle.
Remerciements
Cette version a été renforcée à partir de migrations et de diagnostics effectués sur plusieurs environnements serveur.
Les problèmes rencontrés ont permis d’améliorer des parties essentielles du moteur :
- reprise après interruption ;
- restauration avant le chargement complet de WordPress ;
- comparaison des schémas SQL ;
- traitement des données sérialisées ;
- remplacement des URL ;
- compatibilité avec les caches serveur ;
- gestion des tables personnalisées.