V3.2.7

Notes de version V3.2.7

Performances

• Accélération de la validation et de l’extraction des grandes archives WPCM.
• Stabilisation du dimensionnement adaptatif afin d’éviter les variations excessives entre les blocs de traitement.
• Traitement groupé de milliers de petits fichiers par appel.
• Réduction des synchronisations disque inutiles pendant l’extraction.
• Mise en cache des répertoires déjà contrôlés.
• Import SQL accéléré grâce à des transactions bornées et à des points de reprise atomiques.
• Remplacement des URL optimisé en filtrant directement dans MySQL les lignes réellement concernées.
• Conservation du traitement sécurisé des données sérialisées.

Interface et cache

• Ajout d’un versionnement physique des fichiers JavaScript et CSS par empreinte de contenu.
• Les nouvelles interfaces sont désormais rechargées automatiquement, même derrière un cache navigateur, un CDN ou une extension d’optimisation.
• Amélioration des messages de progression et réduction des entrées répétitives dans le journal.

WP-CLI et récupération

• Ajout des commandes WP-CLI clone-master et de leur alias wpcm.
• Création, liste, inspection, vérification et extraction des sauvegardes depuis le terminal.
• Ajout d’un kit de récupération PHP autonome utilisable lorsque WordPress ne démarre plus.
• Validation complète des archives sans dépendre du thème, des extensions ou du chargement de WordPress.
• Extraction reprenable de database.sql et de wp-content.
• Ajout d’un onglet Secours dans l’administration avec les commandes prêtes à copier.

Importation

• L’onglet de restauration devient Importer.
• Ajout du mode Enregistrer seulement.
• Une archive peut désormais être envoyée, vérifiée et ajoutée à la bibliothèque locale sans restaurer le site.
• Le mode d’enregistrement seul ne modifie ni les fichiers ni la base de données.
• La validation s’effectue sans extraire temporairement tous les fichiers de l’archive.
• Publication atomique de l’archive dans la bibliothèque avec gestion des collisions de noms.

Fiabilité

• Conservation des contrôles SHA-256 par bloc et de la validation finale WPCM.
• Reprise des opérations longues après interruption.
• Publication atomique des archives et des fichiers restaurés.
• Compatibilité maintenue avec les archives générées par les versions précédentes.

V3.2.3

Notes de version V3.2.3

Correction

• Correction d’un faux échec de validation du schéma avec Wordfence et la table wfBlockedIPLog.
• Cette table utilise une clé primaire composite dont la première colonne BINARY(16) possède une valeur par défaut composée de 16 octets nuls.
• MySQL et MariaDB peuvent restituer cette même valeur sous différentes formes via SHOW CREATE TABLE, selon le serveur et le sql_mode, alors que la structure logique reste identique.
• Ajout d’une normalisation portable et ciblée des valeurs par défaut binaires équivalentes.
• Conservation du contrôle SHA-256 pour détecter toute modification du schéma.
• Compatibilité maintenue avec les archives créées par la version 3.2.2.
• Ajout du diagnostic non bloquant installer_schema_binary_default_normalized.

Fiabilité

• Les représentations binaires équivalentes sont désormais acceptées.
• Toute différence de colonne, d’index, de valeur binaire ou de structure continue de bloquer la restauration.

V3.2.2

Notes de version V3.2.2

Améliorations

• Prise en charge sécurisée des tables sans clé PRIMARY ou UNIQUE NOT NULL, avec une stratégie reprenable qui conserve les lignes dupliquées.
• Exclusion automatique des dossiers connus de sauvegarde et de migration afin d’éviter d’embarquer des archives existantes et de gonfler inutilement la sauvegarde.
• Export SQL adaptatif : démarrage progressif, puis augmentation automatique des lots selon les performances de l’hébergement, la mémoire disponible, le temps d’exécution et le volume SQL généré.
• Archivage accéléré grâce à des unités de travail adaptatives, moins de réouvertures de fichiers, une compression sélective et la suppression de vérifications redondantes.
• Progression globale basée sur l’inventaire complet des fichiers et le volume total à traiter.
• Envoi adaptatif et reprenable avec ajustement automatique de la taille des fragments selon le débit, les limites serveur et les erreurs réseau.
• Téléchargement des grandes archives confié au serveur web lorsque cela est possible, avec prise en charge des requêtes HTTP partielles afin de réduire les erreurs Cloudflare 502.
• Analyse et restauration des archives accélérées grâce à un index structurel rapide, suivi d’une validation et d’une extraction adaptatives et reprenables.
• Import SQL et remplacement des URL rendus adaptatifs selon les ressources du serveur et le temps d’exécution.
• Restauration des sites volumineux optimisée grâce au regroupement des opérations de publication de fichiers et à la réduction des lectures inutiles.
• Affichage plus précis de la progression, du débit, du temps restant, de la taille des archives et de la phase en cours.
• Journal d’activité allégé tout en conservant les étapes importantes, les ajustements automatiques, les avertissements et les confirmations de fin.

Fiabilité

• Conservation des doublons dans les tables sans clé unique.
• Export et restauration entièrement reprenables.
• Vérification de l’intégrité par blocs et validation finale de l’archive.
• Prévention de l’inclusion d’anciennes sauvegardes dans les nouveaux exports.
• Publication atomique des archives terminées et des fichiers restaurés.

V3.2.18

Version 3.2.18

• Correction des faux échecs du contrôle de santé après une restauration.
• Nouvelle sonde vérifiant que WordPress a terminé son démarrage.
• Meilleure détection des erreurs fatales, réponses mises en cache et chargements interrompus.
• Nettoyage automatique des fichiers temporaires de diagnostic.

V3.2.17

Clone Master 3.2.17

Cette version fiabilise le contrôle de santé exécuté après une restauration.

Amélioration de la compatibilité avec Nginx et PHP-FPM.

Invalidation d’OPcache et purge du cache objet WordPress après la promotion.

Affichage du véritable message d’erreur PHP avec le fichier et la ligne concernés.

Détection des réponses mises en cache et nouvelles tentatives contrôlées.

3.2.16

Clone Master 3.2.16

Cette version améliore la fiabilité des restaurations volumineuses, en particulier pendant l’étape de remplacement des URL. Elle corrige un problème pouvant provoquer une erreur HTTP 503 lorsque le serveur devait analyser un grand nombre de tables et de lignes au cours d’une seule requête.

Le remplacement des URL repose désormais sur un traitement progressif par lots, avec des points de reprise sécurisés. En cas de surcharge temporaire du serveur, Clone Master réduit automatiquement la quantité de données traitée, attend avant de relancer l’opération, puis reprend depuis le dernier point enregistré sans recommencer l’importation.

Améliorations principales

• Remplacement des URL effectué par lots bornés et reprenables
• Suppression des recherches SQL susceptibles de parcourir intégralement les grandes tables
• Utilisation prioritaire des clés primaires et des index uniques pour parcourir les données
• Réduction automatique de la taille des lots lorsque le serveur montre des signes de saturation
• Reprise automatique après les erreurs temporaires HTTP 409, 429, 500, 502, 503 et 504
• Enregistrement régulier de points de reprise signés pendant le traitement
• Chargement optimisé des métadonnées de la base de données
• Progression calculée à partir des lignes réellement analysées
• Migration automatique des sessions commencées avec l’ancienne méthode de remplacement
• Invalidation du cache JavaScript afin de garantir le chargement des derniers scripts

Sécurité des données

Le moteur de remplacement conserve le traitement sécurisé des données sérialisées. Les valeurs sont désérialisées, parcourues récursivement, modifiées puis resérialisées avant validation.

Des contrôles supplémentaires vérifient également la conservation exacte des valeurs contenant le caractère %, notamment :

• /%postname%/
• %%title%%
• 58%
• les URL contenant %20

Les remplacements globaux directement appliqués aux chaînes sérialisées restent interdits afin d’éviter toute corruption des longueurs de chaînes et des réglages WordPress.

Restauration atomique

Les fichiers et les tables importés restent préparés dans une zone temporaire tant que toutes les étapes de validation ne sont pas terminées. Les données actives du site ne sont remplacées qu’au moment de la promotion finale, après validation de la structure, des volumes et des points de contrôle.

Cette version est particulièrement recommandée pour les sauvegardes contenant plusieurs gigaoctets de fichiers, un grand nombre d’entrées ou de nombreuses tables personnalisées.

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.

V3.2.13

Clone Master 3.2.13

• Correction des exports interrompus lorsqu’un fichier change après l’inventaire.
• Correction des noms de paquets WPCM invalides sur certains environnements.
• Finalisation et vérification du pied WPCM renforcées.
• Correction du téléchargement des sauvegardes avec plusieurs points dans le nom.
• Affichage des dates selon le fuseau horaire WordPress.
• Nettoyage des fichiers temporaires et empreintes orphelines.
• Correction du faux message d’erreur après suppression d’une sauvegarde.
• Compatibilité améliorée avec Nginx, DDEV et les hébergements mutualisés.

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 :

1. validation complète de l’archive .wpcm ;
2. extraction atomique dans un emplacement temporaire ;
3. création des tables de staging ;
4. import de la base de données dans les tables temporaires ;
5. validation du nombre de lignes ;
6. validation des schémas SQL ;
7. remplacement des URL et chemins ;
8. validation des fichiers préparés ;
9. bascule des tables et des fichiers ;
10. contrôle du site restauré ;
11. 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 s...

V1.2

Release Notes - v1.2.0 Update Goliath

Cette mise à jour majeure transforme Clone Master en une solution industrielle capable de gérer les environnements WordPress les plus denses. Nous avons remplacé l'exportation classique par un moteur adaptatif tri-varié conçu pour les bases de données dépassant 2 Go, même sur des serveurs aux ressources limitées.

---

Smart Persistence Engine

L'utilisation de l'API set_transient() de WordPress a été abandonnée pour la gestion du curseur d'exportation.

Pourquoi ce changement ?

Sur les hébergements mutualisés (Hostinger, o2switch, etc.), les transients stockés dans wp_options échouent silencieusement dès que l'objet $state devient trop lourd (liste de +100 tables, métadonnées accumulées). Cela causait des boucles infinies (réinitialisation du curseur à chaque appel).

Clone Master introduit une persistance atomique sur disque via 3 fichiers JSON dédiés :

• db_cursor.json : Stockage ultra-léger de l'index de table et de l'offset actuel.
• db_tables.json : Indexation unique de la structure (testé sur +450 tables).
• db_info.json : Journalisation sécurisée des métadonnées d'export.

** Sécurité Atomique :** Utilisation de la technique write vers .tmp puis rename() pour garantir qu'aucune corruption de fichier ne survient si le serveur interrompt brutalement le script PHP.

---

Adaptive Database Engine 2.0

Le moteur d'exportation analyse désormais votre infrastructure en temps réel pour moduler sa puissance d'exécution :

• ⚡ Accélération intelligente (x1.3) : Sur VPS ou serveurs dédiés (Ionos, OVH Cloud), Goliath libère la puissance pour finir l'export en un temps record.
• 🐢 Mode Survie (x0.5) : Sur les hébergements restrictifs, l'algorithme réduit automatiquement la voilure (ex: lots de 200 lignes) pour rester sous les seuils de saturation RAM et éviter les erreurs 503/504.
• 🔍 Anticipation SQL : Analyse préventive du poids des données (colonnes LONGTEXT, BLOB) pour éliminer l'erreur fatale MySQL avant qu'elle ne survienne.