Cet outil migre un site WordPress depuis un ancien hébergeur vers un nouveau,
en 3 écrans : Configuration (saisir les accès), Suivi en temps réel
(voir l'avancement) et Recherche / Remplacement (corriger les URL dans la base
une fois la migration terminée).
1. Écran « Configuration »
C'est l'écran de départ. Tu y renseignes les accès aux deux serveurs (l'ancien
et le nouveau), tu choisis quel backup migrer, et tu lances la migration. La page
est divisée en 4 cartes à remplir de haut en bas.
Carte 1 — Serveur source (accès FTP)
Le serveur source, c'est l'ancien hébergeur où ton site WordPress est
actuellement. L'outil s'y connecte en FTP pour récupérer le backup
(un fichier .zip contenant les fichiers WordPress et un dump de la base).
| Champ | À quoi ça sert | Exemple |
|---|
| Adresse FTP | Le nom d'hôte du serveur FTP source | ftp.monancienhebergeur.com |
| Port | Port FTP. Laisse 21 sauf indication contraire de l'hébergeur | 21 |
| Identifiant FTP | Le login FTP (donné par l'ancien hébergeur) | monlogin |
| Mot de passe FTP | Le mot de passe FTP. L'icône 👁 permet de l'afficher pour vérifier la frappe | — |
| Dossier source FTP | Le chemin où se trouvent les backups, relatif au home FTP | /backup-manager/data/backups/ |
Important — chemin relatif au home FTP. La plupart des serveurs FTP
appliquent un cloisonnement (« chroot ») : tu n'as pas accès à toute l'arborescence
du serveur, seulement à ton home. Donc /home2/monuser/backup-manager/...
ne marche en général PAS — il faut utiliser /backup-manager/....
L'outil tente automatiquement de retirer le préfixe si tu te trompes, mais ce n'est
pas garanti sur tous les hébergeurs.
Une fois les 5 champs remplis, clique sur « Tester la connexion FTP ».
Une coche verte apparaît si la connexion réussit, et la Carte 2 (liste
des backups) s'affiche automatiquement en dessous.
Erreurs courantes :
- « Connexion refusée » → adresse FTP, port ou pare-feu. Vérifie les 3.
- « Identifiants invalides » → login ou mot de passe incorrect.
- « Listage du dossier distant refusé » → le chemin saisi n'existe pas, ou tu utilises un chemin filesystem absolu (cf. encadré ci-dessus).
Carte 2 — Choisir le backup à migrer
Cette carte n'apparaît qu'après un test FTP réussi. Elle liste tous les backups
détectés dans le dossier source, triés par date. Chaque ligne affiche :
- Date du backup (extraite du nom de fichier
backup_AAAA-MM-JJ_HH-MM-SS.zip)
- Taille du fichier en mégaoctets
- Format détecté — l'outil reconnaît 6 formats numérotés selon comment le backup est structuré : Format 1 — ZIP unique mixte, Format 2 — ZIP + SQL séparé, Format 3 — ZIP + SQL compressé, Format 4 — Deux ZIP, Format 5 — ZIP imbriqué + SQL brut, Format 6 — ZIP imbriqué + SQL compressé. Certains ne peuvent être tranchés qu'après extraction : ils sont marqués « à confirmer après extraction », l'outil le résoudra automatiquement plus tard.
Coche la ligne du backup que tu veux migrer. Tant qu'aucun backup n'est sélectionné,
le bouton « Démarrer la migration » en bas de page reste désactivé.
Aucun backup reconnu ? Vérifie que les fichiers respectent le
format backup_AAAA-MM-JJ_HH-MM-SS.zip. Les fichiers au mauvais format
(sans date dans le nom, ou extension autre que .zip) sont ignorés et
listés en bas de carte sous « Fichiers ignorés ».
Carte 3 — Serveur destination (base de données)
Le serveur destination, c'est le nouvel hébergeur — celui sur lequel cet
outil tourne en ce moment. Tu renseignes ici les accès à la base MySQL où l'outil
importera la base WordPress, puis le dossier où il déposera les fichiers.
| Champ | À quoi ça sert | Exemple |
|---|
| Hôte MySQL | Adresse du serveur MySQL. Sur les hébergeurs mutualisés c'est presque toujours localhost | localhost |
| Nom de la base | Nom de la base MySQL (créée à l'avance dans cPanel) | monuser_wp |
| Identifiant MySQL | Login de l'utilisateur MySQL associé à cette base | monuser_wp |
| Mot de passe MySQL | Mot de passe MySQL. Icône 👁 pour vérifier la frappe | — |
| Dossier destination des fichiers | Chemin où l'outil copiera les fichiers WordPress (wp-content, wp-config, etc.). Relatif au home utilisateur | /data/mon-site/public_html/ |
Le bouton « Tester MySQL » vérifie la connexion. Comme l'outil
tourne déjà sur le serveur destination, le test se fait en local :
le mot de passe MySQL ne transite jamais par le réseau.
Dossier destination vide = migration BDD seule. Si tu laisses ce
champ vide, l'outil n'importera que la base de données et tu devras déployer les
fichiers WordPress à la main. Pour une migration complète, indique le chemin du
DocumentRoot du sous-domaine cible (le dossier sur lequel pointe ton sous-domaine).
Erreurs courantes :
- « Access denied for user » → identifiant ou mot de passe MySQL incorrect.
- « Unknown database » → la base n'existe pas, crée-la d'abord dans cPanel.
- « Base non vide » → la base contient déjà des tables. Ce n'est pas bloquant ici, c'est l'option de la Carte 4 qui décidera quoi en faire.
Carte 4 — Options de migration
| Option | Rôle |
|---|
| Type de migration |
Pour l'instant un seul mode : Migration complète (fichiers + base). |
| Ancienne URL source |
L'URL actuelle du site WordPress sur l'ancien hébergeur. Ex : https://www.monancienhebergeur.com.
Cette URL est utilisée par Search & Replace pour mettre à jour automatiquement la base après import. |
| Nouvelle URL destination |
L'URL où le site sera accessible après migration. Ex : https://www.monnouvelhebergeur.com. |
| Si des fichiers existent déjà |
Que faire si le dossier destination contient déjà des fichiers :
- Demander confirmation — l'outil s'arrête et te demande
- Écraser sans demander (par défaut) — remplace tout
- Ignorer — conserve les fichiers existants, ajoute seulement les manquants
- Annuler si dossier non vide — sécurité maximale
|
| Si la base de données n'est pas vide |
Que faire si la base MySQL contient déjà des tables :
- Demander confirmation — l'outil s'arrête et te demande
- Vider et importer — supprime toutes les tables existantes (irréversible !) puis importe
- Annuler si non vide (par défaut) — sécurité maximale
|
Boutons en bas de page
- Enregistrer le brouillon — envoie une copie du brouillon au serveur (en plus du localStorage). Utile pour reprendre depuis un autre poste sur le même domaine.
- Démarrer la migration — déclenche la migration. Bouton désactivé tant qu'aucun backup n'est sélectionné dans la Carte 2. Le test FTP et le remplissage des accès MySQL ne sont pas vérifiés à ce stade — c'est ta responsabilité de t'assurer qu'ils sont corrects, sinon la migration échouera plus tard. Une fois cliqué, l'écran Suivi en temps réel s'ouvre automatiquement.
Sauvegarde automatique au fil de la saisie. Tout ce que tu tapes
dans les champs (sauf les mots de passe FTP et MySQL, qui ne sont jamais stockés)
est enregistré dans le localStorage du navigateur en temps réel. Si
tu fermes l'onglet et tu reviens plus tard, les champs seront restaurés tels quels.
2. Écran « Suivi en temps réel »
Cet écran s'affiche automatiquement quand tu cliques sur Démarrer la migration.
Il te montre l'avancement en direct : quelle phase est en cours, ce qui a été transféré,
les éventuelles alertes ou erreurs, et te donne les boutons pour piloter la migration
(pause, reprendre, recommencer, annuler).
Barre d'actions (en haut)
À gauche, un indicateur d'état (En attente, En cours, En pause,
Terminée, Erreur, Annulée). À droite, 4 boutons :
| Bouton | À quoi ça sert | Disponible quand… |
|---|
| Mettre en pause |
Suspend la migration à la fin du chunk en cours (pas instantané — un chunk peut durer quelques secondes) |
Migration en cours |
| Reprendre |
Reprend depuis le dernier checkpoint sauvegardé. Aucun fichier déjà transféré n'est retransféré (règle CDC R4) |
Migration en pause OU en erreur |
| Recommencer |
Relance la migration depuis le début. Une modale demande confirmation : les données déjà transférées seront supprimées |
Migration en cours, en pause, en erreur ou annulée — pas après une migration terminée avec succès |
| Annuler & nettoyer |
Une modale confirme. L'agent PHP est supprimé du serveur destination ; les données partielles déjà transférées restent sur place (à nettoyer manuellement si besoin) |
Migration en cours, en pause ou en erreur |
Pendant que la migration tourne, les champs de Configuration sont verrouillés
(grisés, non éditables). Ils redeviennent modifiables quand la migration est terminée,
en erreur, ou annulée — utile si tu veux relancer avec d'autres paramètres.
Cartes serveurs source & destination
Sous la barre d'actions, deux cartes côte à côte récapitulent les deux serveurs
de la migration :
- Serveur source — l'hôte FTP saisi dans Configuration. Statut En attente au démarrage, puis Lecture pendant le téléchargement du backup.
- Serveur destination (ce serveur) — le serveur sur lequel tu utilises l'outil. Statut En attente puis Écriture pendant l'extraction et l'import.
Ces cartes sont surtout informatives : elles te confirment que le bon FTP est ciblé.
Phases & barre de progression
La migration se déroule en 5 grandes phases, affichées sous forme
d'étapes (cercles + libellés). Une phase passe au vert avec une coche dès qu'elle
est terminée.
| Phase | Ce que fait l'outil |
|---|
| 1. Vérification | Teste les accès FTP, MySQL, et l'espace disque sur la destination |
| 2. Sauvegarde source | Télécharge le backup depuis le FTP source (fichier .zip) |
| 3. Transfert fichiers | Décompresse l'archive et installe les fichiers WordPress dans le dossier destination |
| 4. Installation destination | Importe le dump SQL dans la base MySQL puis applique le Search & Replace automatique sur les URL |
| 5. Nettoyage | Supprime les fichiers temporaires (extraction, dumps), puis l'agent lui-même à la fin |
Sous les phases, une barre de progression globale (0 → 100 %) avec
une estimation de temps restant (« Estimation : … »), et un chronomètre
en haut à droite (format HH:MM:SS) qui compte depuis le démarrage.
Quand une phase est en cours, une carte « Opération en cours »
apparaît juste en dessous : elle affiche l'action ponctuelle (ex : « Transfert
de wp-content/uploads/2024/photo.jpg ») et les compteurs Transférés / Restants / Débit.
Métriques temps réel
Une grille de 4 cartes au milieu de l'écran récapitule l'état chiffré de la migration :
| Métrique | Détail |
|---|
| Données transférées | Volume cumulé téléchargé depuis le serveur source. Affiché en v1.0.1. |
| Fichiers | Câblé en v1.0.0. Format X / Y — fichiers transférés / total détecté. Mis à jour à chaque checkpoint. |
| Base de données | Taille du dump SQL et progression de l'import. Affiché en v1.0.1. |
| Erreurs / Alertes | Compteur des entrées WARNING / ERROR / CRITICAL du journal. Affiché en v1.0.1. |
« Affiché en v1.0.1 » — qu'est-ce que ça veut dire ? Ces 3 cartes
afficheront un tiret (—) en v1.0.0 même quand la migration tourne :
le calcul côté serveur sera ajouté à la version suivante. Ce ne sont pas des
erreurs, c'est attendu.
Journal de migration & filtres
La console en bas d'écran affiche en direct les logs de la migration.
Chaque entrée a un horodatage, un niveau de gravité, et un message. Quatre filtres
permettent de masquer ce qui ne t'intéresse pas :
| Filtre | Ce qui est affiché |
|---|
| Tout | Toutes les entrées (par défaut) |
| ✓ OK | Niveau INFO uniquement (étapes franchies, messages d'avancement) |
| ⚠ Alertes | Niveau WARNING (anomalies non bloquantes — ex : un fichier ignoré) |
| ✗ Erreurs | Niveaux ERROR et CRITICAL (problèmes graves — l'outil utilise CRITICAL pour les rejets de sécurité, ex : signature HMAC invalide) |
En haut à droite de la console : un bouton « ↓ Télécharger » qui
exporte le journal complet en fichier texte (utile pour le support ou pour archiver
la migration). En bas : un compteur d'entrées et une case « Défilement auto »
(cochée par défaut) qui fait défiler automatiquement vers la dernière ligne — décoche-la
si tu veux relire des entrées passées sans qu'elles soient écrasées.
Fin de migration (succès ou erreur)
✓ Migration réussie
Une carte verte « Migration terminée avec succès » apparaît avec
un récapitulatif (durée totale, fichiers transférés, tables importées) et deux boutons :
- Ouvrir le nouveau site — ouvre l'URL destination dans un nouvel onglet
- Terminer et nettoyer — supprime les fichiers de travail temporaires (dossier d'extraction, dumps SQL, fichiers de credentials chiffrés). L'agent reste en place pour de futures migrations sur ce serveur.
✗ Migration en erreur
Une carte rouge apparaît avec un titre, un code d'erreur (ex :
WPM_RUNTIME_005) et un message expliquant ce qui n'a pas marché.
Tu as 3 options :
- Reprendre depuis le checkpoint — si l'erreur est transitoire (réseau, timeout), retente sans tout refaire
- Recommencer depuis 0 — efface ce qui a été transféré et redémarre intégralement (modale de confirmation)
- Annuler & nettoyer — abandonne la migration et supprime l'agent
La signification de chaque code d'erreur (WPM_BLOCKING_* et
WPM_RUNTIME_*) est listée dans la section 4 de cette doc.
Bandeau de sécurité (en bas)
Une bande bleue tout en bas rappelle deux choses :
- Toutes les requêtes vers l'API sont signées en HMAC-SHA256 avec un secret partagé entre le navigateur et le serveur. Une requête sans signature valide est rejetée (CRITICAL dans le journal).
- L'agent reste en place par défaut, prêt pour de futures migrations sur ce serveur. Il n'est supprimé que si tu cliques sur « Annuler & nettoyer ». L'option « Terminer et nettoyer » en fin de migration supprime uniquement les fichiers de travail temporaires, pas l'agent.
À droite du bandeau, un badge TOKEN affiche les 8 premiers / 4 derniers
caractères du jobId courant — utile pour identifier la migration dans les logs ou
le support.
3. Écran « Recherche / Remplacement »
Cet écran sert à modifier des chaînes de caractères directement dans la base
MySQL d'un site WordPress, en respectant les données sérialisées PHP. C'est un
outil indépendant : tu peux l'utiliser sans avoir lancé de migration. Toute
modification est irréversible sans backup — l'écran t'oblige donc
à passer par une prévisualisation avant d'exécuter quoi que ce soit.
À quoi ça sert (et quand l'utiliser)
Pendant une migration normale, l'outil applique automatiquement un
Search & Replace en phase 4 pour remplacer l'ancienne URL par la nouvelle. Cet écran
existe pour les cas exceptionnels où tu dois faire une opération
ponctuelle qu'une migration ne couvre pas :
- Corriger une URL mal renseignée après-coup (ex : tu as migré vers
https://nouveau.fr mais voulais https://www.nouveau.fr)
- Renommer un préfixe de tables, un nom de domaine partenaire, un identifiant, etc.
- Nettoyer des chaînes laissées par un thème ou un plugin qui n'utilise pas l'URL standard
Ne pas confondre avec la migration. Cet écran n'a aucun lien avec
le processus de migration en cours ou passé. Il agit en direct sur la base MySQL
que tu lui désignes — typiquement la base destination que tu viens de migrer, mais
ça peut être n'importe quelle base WordPress accessible depuis le serveur.
Carte 1 — Connexion à la base
4 champs MySQL et un bouton Tester la connexion :
| Champ | Détail |
|---|
| Hôte MySQL | Pré-rempli avec localhost (cas standard sur o2switch). À changer uniquement si la base est sur un autre serveur. |
| Nom de la base | Le nom exact de la base WordPress (ex : monsite_wp). |
| Identifiant MySQL | Utilisateur MySQL ayant les droits SELECT et UPDATE sur cette base. |
| Mot de passe MySQL | Affiché en ••• par défaut. Une icône œil à droite permet de le rendre visible le temps de vérifier ta saisie. |
Tester la connexion envoie une requête à /api/sr/test-db.php
qui ouvre une connexion PDO et compte les tables. Réponse OK :
✓ Connecté — 14 table(s) détectée(s) — 11.4.10-MariaDB
En cas d'échec, le message indique la cause (mot de passe incorrect, base inexistante,
hôte injoignable, etc.). Aucune modification n'est faite à ce stade.
Carte 2 — Termes & options
- Rechercher — la chaîne exacte à trouver (ex :
https://www.ancien-site.com). Police monospace pour bien voir les caractères. Champ obligatoire ; vide → l'aperçu refuse avec WPM_VALIDATION_FAILED.
- Remplacer par — la chaîne qui prendra la place. Peut être vide (équivalent à supprimer toutes les occurrences).
- Sensible à la casse — case à cocher d'apparat en v1.0.0. Le moteur applique
str_replace, qui est toujours sensible à la casse ; cocher ou décocher la case ne change rien. Câblage prévu en v1.0.1.
- Toutes les tables — case à cocher d'apparat en v1.0.0 (le moteur scanne déjà toutes les tables de la base, peu importe leur préfixe). Câblage prévu en v1.0.1.
Deux boutons en bas :
- 👁 Prévisualiser — toujours cliquable. Lance la recherche et compte les occurrences sans rien modifier.
- ✓ Exécuter — désactivé tant qu'aucune prévisualisation valide n'a été faite. C'est la règle M7 (preview obligatoire) — il est impossible de modifier la base sans avoir vu d'abord ce qui sera changé.
Carte 3 — Prévisualisation (obligatoire)
Après un clic sur 👁 Prévisualiser, une carte apparaît avec :
- Un compteur « Prévisualisation — N occurrences » en haut
- Un avertissement jaune rappelant que l'action sera irréversible sans backup
- Un tableau ligne par table : Table, Colonnes scannées, Occurrences trouvées, indicateur Sérialisé
- Un gros bouton ▶ Exécuter (N occurrence(s)) à droite
Le bouton « Exécuter » est associé à un jeton de prévisualisation
(previewToken) avec une durée de vie de 10 minutes.
Si tu attends trop longtemps avant de cliquer, tu auras un refus
WPM_PREVIEW_TOKEN_INVALID. Refais simplement une prévisualisation —
le compteur d'occurrences sera recalculé sur l'état courant de la base.
La colonne Sérialisé indique les colonnes qui contiennent des données
sérialisées PHP (typiquement wp_options, wp_postmeta,
theme_mods_*). L'outil sait les manipuler proprement — il recalcule les
longueurs de chaînes (s:N:) après remplacement, pour ne pas casser la
structure.
Carte 4 — Rapport d'exécution
Après le clic sur ▶ Exécuter, l'outil applique les remplacements
et affiche une carte verte « ✓ Remplacement terminé » avec 3 chiffres :
| Métrique | Détail |
|---|
| Remplacements | Nombre total de chaînes remplacées. Peut être plus grand que le compteur de la prévisualisation : la prévisualisation compte les lignes impactées, l'exécution compte chaque occurrence (une ligne sérialisée peut en contenir plusieurs). |
| Tables modifiées | Nombre de tables ayant eu au moins une ligne mise à jour. |
| Avertissements | Compteur d'incidents non bloquants (ex : valeur sérialisée corrompue avant l'opération, ignorée par sécurité). Idéalement 0. |
Un bouton Nouvelle recherche en bas masque les cartes Prévisualisation
et Rapport pour repartir d'un écran propre.
Garde-fous & sécurité
3 règles du CDC sont appliquées sur cet écran :
| Règle | Comportement |
|---|
| M7 — preview obligatoire | Le bouton Exécuter est désactivé tant qu'une prévisualisation valide n'a pas été générée. Le backend refuse execute.php sans previewToken. |
| M2 — recalcul byte-exact des chaînes sérialisées | Pour chaque s:N:"…" rencontré, l'outil recalcule N après remplacement. Sinon unserialize() retournerait false et WordPress afficherait un site cassé. |
| M8 — désérialisation sécurisée | Tout appel à unserialize() est fait avec l'option allowed_classes => false. Cela neutralise une classe d'attaques (gadget chains) où une chaîne O: stockée en base déclencherait du code en désérialisation. |
Tu peux tester l'innocuité de M8 toi-même. Mets dans le champ
Rechercher la chaîne O:8:"stdClass":0:{} et clique
Prévisualiser. La page reste stable, l'outil retourne le nombre
d'occurrences (souvent 0 ou 2 selon les plugins), et aucune classe n'est
instanciée côté serveur. Si l'agent était vulnérable, on verrait un crash PHP
ou une stack trace.
4. Codes d'erreur & glossaire
Quand quelque chose se passe mal, l'outil affiche un code d'erreur
de la forme WPM_BLOCKING_007 ou WPM_RUNTIME_005. Ces codes
sont stables : ils ne changent pas d'une version à l'autre, et tu peux les retrouver
tels quels dans le journal pour diagnostiquer.
Comment lire un code d'erreur
Un code suit toujours le format WPM_<catégorie>_<identifiant> :
| Catégorie | Quand ? | Effet |
|---|
BLOCKING |
Avant le démarrage d'une migration ou en pré-vérification |
L'opération est refusée, rien n'a été modifié sur le serveur |
RUNTIME |
Pendant la migration (téléchargement, extraction, import SQL, etc.) |
La migration passe en état Erreur. Tu peux Reprendre depuis le checkpoint ou Recommencer. |
VALIDATION_FAILED |
Champ vide ou format invalide envoyé au backend |
Refus immédiat, message dans la zone de résultat. Aucun effet de bord. |
JOB_* / DRAFT_* / PREVIEW_* |
Cas techniques (état jobId, brouillon, jeton S&R) |
Variable selon le contexte — détaillé plus bas |
Les codes BLOCKING et RUNTIME remontent aussi
dans le journal de migration (console de l'écran Suivi), avec un niveau
ERROR ou CRITICAL selon la gravité. Tu peux les filtrer
avec le chip « ✗ Erreurs ».
Codes BLOCKING (avant migration)
Ces codes sont retournés par les tests de pré-migration ou en
début de phase 1, avant que quoi que ce soit ne soit modifié.
| Code | Signification | Que faire |
|---|
WPM_BLOCKING_001 |
Connexion FTP échouée — host injoignable, port fermé, ou pré-condition manquante (chemin invalide). |
Vérifier Hôte, Port et la connectivité réseau depuis le serveur destination vers le FTP source. |
WPM_BLOCKING_002 |
Connexion à la base MySQL refusée. Ou mode « Annuler si la base n'est pas vide » et la base contient déjà des tables. |
Vérifier identifiant et mot de passe MySQL. Si tu veux écraser une base non vide, choisis « Vider la base et importer » dans les options. |
WPM_BLOCKING_004 |
Espace disque insuffisant sur le serveur destination (vérifié par HealthCheck avant le téléchargement). |
Libérer de l'espace via cPanel ou contacter l'hébergeur. Le seuil est dimensionné pour la taille du backup × 2. |
WPM_BLOCKING_005 |
L'extension PHP pdo_mysql n'est pas activée sur le serveur destination. |
Activer pdo_mysql dans le panneau PHP de l'hébergeur. Sur o2switch, cela se fait via Sélecteur PHP → Extensions. |
WPM_BLOCKING_007 |
Échec de signature HMAC ou nonce déjà utilisé (anti-rejeu). C'est le code unique pour tout rejet de sécurité côté authentification d'API. |
Si tu vois ce code à l'usage normal, recharge la page (Ctrl+F5) — le secret HMAC peut être désynchronisé. Sinon, c'est probablement une vraie tentative d'accès non signée — ne pas ignorer. |
WPM_BLOCKING_009 |
Mode « Annuler si dossier non vide » pour les fichiers et le dossier destination contient déjà des fichiers. |
Soit vider le dossier destination manuellement, soit changer l'option en « Écraser sans demander ». |
Codes RUNTIME (pendant migration)
Ces codes apparaissent quand la migration a démarré et qu'un problème survient
pendant une phase. Ils placent la migration en état Erreur avec la possibilité
de reprendre depuis le checkpoint.
| Code | Signification | Que faire |
|---|
WPM_RUNTIME_003 |
Interruption réseau pendant un transfert FTP. |
Cliquer Reprendre depuis le checkpoint. Les fichiers déjà téléchargés ne sont pas retransférés. |
WPM_RUNTIME_005 |
Échec runtime générique en phase 4 — typiquement truncate BDD impossible (mot de passe MySQL devenu invalide), import SQL qui échoue, ou erreur de déploiement de fichiers. |
Lire le message complet dans la carte d'erreur ou le journal. Souvent dû à des credentials qui ont changé entre le démarrage et l'exécution. |
WPM_RUNTIME_FORMAT_UNKNOWN |
Le fichier sélectionné comme backup n'a pas pu être identifié comme un format connu (Format 1 à 6 du CDC). |
Vérifier que le fichier est bien un backup WordPress et qu'il n'est pas corrompu. L'outil reconnaît 6 formats — au-delà, il refuse plutôt que d'extraire à l'aveugle. |
WPM_RUNTIME_FORMAT4_NO_SQL |
Format 4 (Deux ZIP) attendu, mais aucun dump SQL trouvé dans la deuxième archive. |
Le backup est probablement incomplet. Régénérer un backup complet à la source. |
WPM_RUNTIME_SQL_GHOST_ONLY |
L'archive ne contient qu'un dump SQL (« fantôme »), pas les fichiers WordPress. |
Le backup n'est pas exploitable seul — il faut aussi les fichiers wp-content/ et la structure WordPress. |
WPM_RUNTIME_ZIP_INVALID |
Le fichier n'est pas un ZIP valide (signature en-tête incorrecte). |
Le téléchargement a probablement été tronqué. Refaire la migration ; si ça persiste, le fichier source est corrompu. |
WPM_RUNTIME_ZIP_BOMB |
Garde-fou de sécurité M9 : la somme des tailles décompressées dépasse 10× la taille de l'archive (signe d'une zip-bomb). |
Refus volontaire. Si tu es certain que le backup est légitime malgré son fort ratio de compression, ouvre une issue v1.0.1. |
WPM_RUNTIME_PATH_TRAVERSAL |
Garde-fou M9 : une entrée du ZIP a un chemin qui sort du dossier d'extraction (ex : ../../etc/passwd). |
Refus volontaire — l'archive contient des entrées malveillantes. Ne jamais ignorer ce code. |
Codes Search & Replace
| Code | Signification | Que faire |
|---|
WPM_VALIDATION_FAILED |
Champ vide ou invalide envoyé à /api/sr/preview.php ou /api/sr/execute.php. Le plus souvent : champ Rechercher vide. |
Remplir tous les champs requis (au minimum Rechercher et la connexion BDD complète). |
WPM_PREVIEW_TOKEN_INVALID |
Le jeton de prévisualisation est expiré (TTL 10 min) ou a été altéré côté navigateur. |
Refaire un clic Prévisualiser — un nouveau jeton est généré, valide pour 10 min. |
WPM_PREVIEW_TOKEN_MISMATCH |
Les paramètres envoyés à execute.php ne correspondent pas à ceux qui avaient été prévisualisés (ex : la chaîne Rechercher a été modifiée entre les deux). |
Refaire Prévisualiser avec les paramètres exacts que tu veux exécuter, puis cliquer Exécuter sans rien retoucher. |
Codes techniques (jobId, brouillon)
Tu ne devrais jamais croiser ces codes en usage normal. Ils sont listés ici pour
référence si tu inspectes l'API directement (curl, scripts).
| Code | Signification |
|---|
WPM_MISSING_JOB_ID | Aucun jobId dans la requête (ni en query string, ni en body). |
WPM_INVALID_JOB_ID | jobId ne respecte pas le format attendu : alphanumérique + _ + -, longueur entre 8 et 64 caractères (regex /^[A-Za-z0-9_-]{8,64}$/). |
WPM_JOB_NOT_FOUND | Aucun fichier d'état trouvé pour ce jobId (job jamais créé ou déjà nettoyé). |
WPM_JOB_READ_FAILED | Le fichier d'état existe mais n'a pas pu être lu (permissions, JSON corrompu). |
WPM_DRAFT_DIR_FAILED | Création du dossier storage/drafts/ impossible (permissions). |
WPM_DRAFT_ENCODE_FAILED | Le brouillon contient des données qui ne se sérialisent pas en JSON. |
WPM_DRAFT_WRITE_FAILED | Écriture du brouillon sur disque impossible (espace plein, permissions). |
Glossaire
Termes techniques utilisés dans la doc et dans le journal de migration :
| Terme | Définition |
|---|
| Agent |
Le code PHP de l'outil, déposé sur le serveur destination. Par défaut, l'agent reste en place pour servir à de futures migrations sur le même serveur. Il n'est supprimé que via le bouton Annuler & nettoyer. |
| Backup |
Archive ZIP contenant les fichiers WordPress et un dump SQL. L'outil reconnaît 6 formats (numérotés Format 1 à 6) selon la structure interne de l'archive. |
| Brouillon |
Sauvegarde des champs de Configuration que tu as remplis (sauf mots de passe). Stocké dans le navigateur (localStorage) ainsi qu'au serveur quand tu cliques le bouton dédié. |
| Checkpoint |
État sauvegardé à intervalle régulier pendant la phase 3. En cas d'erreur ou de pause, la migration peut reprendre à partir du dernier checkpoint sans tout retransférer. |
| CDC |
« Cahier des charges » — document de référence qui définit le comportement attendu de l'outil. Les règles citées dans la doc (M2, M7, M8, M9, R4) sont des numéros de section du CDC. |
| CRITICAL |
Niveau de log le plus haut, utilisé pour les opérations irréversibles (DROP TABLE par exemple) et les rejets de sécurité (HMAC invalide). À surveiller dans le journal. |
| Données sérialisées |
Format de stockage PHP utilisé par WordPress pour les options complexes (widgets, theme_mods, etc.). Une chaîne sérialisée commence souvent par a:, O: ou s:N:"…" et contient sa propre longueur — d'où la nécessité de la recalculer (M2). |
| Dump SQL |
Export texte d'une base MySQL (suite de CREATE TABLE et INSERT). C'est ce qu'on importe en phase 4 dans la base destination. |
| HMAC |
Signature cryptographique (HMAC-SHA256) qui authentifie chaque requête entre le navigateur et l'API. Sans une signature valide, l'API renvoie WPM_BLOCKING_007. |
| jobId |
Identifiant unique d'une migration. Inscrit dans tous les fichiers de travail (storage/jobs/<jobId>.json, storage/logs/<jobId>.log). Affiché en bas à droite de l'écran Suivi. |
| Migration |
Opération complète qui télécharge un backup depuis un FTP source, l'extrait, importe la base, applique le Search & Replace automatique sur les URL, et déploie les fichiers WordPress dans le dossier destination. Découpée en 5 phases. |
| Nonce |
Identifiant à usage unique inclus dans chaque requête signée. Évite qu'un attaquant rejoue une requête déjà valide. Tout nonce déjà vu → rejet WPM_BLOCKING_007. |
| Phase |
Étape de la migration. Les 5 phases sont : Vérification, Sauvegarde source, Transfert fichiers, Installation destination, Nettoyage. |
| previewToken |
Jeton de prévisualisation S&R, valide 10 minutes. Lié à un triplet exact (search, replace, scope). Sans lui, execute.php refuse — c'est la règle M7. |
| Search & Replace |
Opération qui parcourt toutes les tables d'une base MySQL et remplace une chaîne par une autre, en respectant les données sérialisées. Appliqué automatiquement en phase 4 sur les URL ; aussi disponible manuellement via l'écran dédié. |
| Tick |
Cycle d'exécution court (~25 s) utilisé pour respecter max_execution_time = 30 s sur o2switch mutualisé. Une migration est constituée d'une suite de ticks, chacun déclenché par le polling JavaScript. |
| WPM |
« WordPress Migration » — préfixe de tous les codes d'erreur applicatifs de l'outil. |