Relever l’opération qui a été interrompue à l’écran
Vous lancez un import WordPress, attendez longtemps et recevez une page Cloudflare affichant 524. Une partie des articles apparaît pourtant dans l’administration. Lors d’un export, le navigateur peut au contraire recevoir une page d’erreur à la place du fichier attendu. Relevez l’opération, le fichier ou le lot utilisé, l’heure de départ et l’heure de la coupure. Conservez l’adresse de la requête et l’identifiant Ray affiché lorsque vous l’avez. Vérifiez le type du fichier téléchargé avant de le considérer comme un export. Un fichier nommé XML peut contenir une page HTML d’erreur.
Le résultat à établir est l’état du traitement après cette coupure. Selon l’outil et l’environnement, il peut s’arrêter, continuer ou laisser des écritures partielles. La réponse du navigateur ne permet pas de choisir entre ces cas. Évitez les relances pendant le relevé initial. Demandez un accès à l’état des imports et aux journaux à la personne qui exploite le site si vous n’avez que l’écran d’administration. Un compte autorisé à importer et une copie privée suffisent pour préparer une reprise reproductible.
Relier le statut 524 au délai du proxy
Cloudflare décrit 524 comme une connexion établie à l’origine dont la réponse arrive trop tard. La documentation relevée le 4 novembre 2026 indique un délai de lecture par défaut de 125 secondes. Vérifiez la valeur effective de l’offre au moment du diagnostic. Elle décrit aussi un délai d’écriture distinct lorsqu’un envoi vers l’origine n’aboutit pas dans le temps permis. Comparez la durée observée au type de demande. Un téléchargement long, une préparation d’export et un gros envoi de fichier ne passent pas forcément par le même moment de blocage. Relevez le statut du serveur d’origine au même instant si ce relevé existe.
La limite de PHP, le délai du serveur web et celui du proxy sont des réglages différents. Modifier une seule valeur peut déplacer le point d’échec. Avant de demander un changement, vérifiez si le serveur reste occupé, si une requête SQL dure longtemps ou si l’import attend des médias distants. Si le travail démarre rapidement puis ne produit aucune progression, cette étape devient la piste. Si l’opération avance mais dépasse régulièrement la fenêtre, un fractionnement ou un traitement suivi convient mieux à l’usage. Gardez les valeurs effectives de votre offre et de votre configuration dans le bilan.
Vérifier si le traitement continue après la coupure
Dans l’outil qui a lancé l’opération, recherchez l’historique, le journal ou la file de traitement. Relevez l’identifiant du travail et la dernière étape terminée. Attendez une période de contrôle adaptée puis relisez le même état. Une progression des compteurs ou une nouvelle entrée de journal montre que le traitement avance encore. Une absence de progression ne démontre pas immédiatement son arrêt. Le mainteneur peut vérifier les processus et les journaux serveur pour rapprocher la requête de l’opération en cours.
Pour un import natif dans Outils puis Importer puis WordPress, examinez quelques contenus reconnaissables du fichier. Comparez le début, le milieu et la fin du lot, ainsi que les pièces jointes attendues. Le nombre total d’articles ne suffit pas si le site contenait déjà des éléments. Relevez les identifiants créés et les erreurs visibles. Pour un export, vérifiez si un fichier complet existe dans l’emplacement annoncé par l’outil ou si le navigateur n’a reçu qu’un flux incomplet. La présence d’un fichier ou d’un article témoin ne valide pas tout le lot.
Conserver un point de comparaison avant la reprise
Préparez une copie cohérente de l’état après incident et retrouvez le point de restauration qui précède l’opération si vous en disposez. Gardez le fichier d’entrée original, son empreinte et les réglages d’import. Notez l’association des auteurs, les options de pièces jointes et les règles de mise à jour des contenus. Si une intégration a transmis des données à un service externe, vérifiez aussi les effets déjà produits. Un nouvel import peut répéter ces actions même si certains articles sont reconnus comme existants.
Avant tout import sur la copie, neutralisez ou redirigez vers un circuit de test les courriels, webhooks, synchronisations et autres actions sortantes. Une copie du site peut conserver les destinations et secrets actifs ; son caractère privé ne suffit pas à isoler ces effets.
Sur cette copie préparée, comparez les contenus réellement importés à l’inventaire du lot. Choisissez comment reconnaître une ligne déjà traitée, par exemple une clé stable de l’importeur qui identifie le contenu source. L’intitulé seul peut correspondre à plusieurs articles. Si l’outil ne fournit ni reprise contrôlée ni clé fiable, revenez sur la copie au point précédant le lot pour répéter avec un périmètre plus petit. Sur un site actif qui reçoit d’autres écritures, faites définir le retour ciblé avant toute restauration. Les données arrivées depuis le point de départ doivent être conservées.
Reprendre uniquement le travail identifié comme manquant
Quand l’outil propose une reprise documentée, utilisez l’identifiant du travail existant et les options prévues. Vérifiez si la reprise continue une file ou recommence le fichier complet. Dans le second cas, examinez les règles de correspondance et les effets répétés. Sur la copie, préparez un petit sous-lot contenant une ligne déjà traitée et une ligne manquante. Vérifiez les deux résultats avant d’étendre le périmètre. Une mise à jour de contenu et une création doivent rester distinguables dans le rapport de l’importeur.
Si vous utilisez l’importateur natif sans reprise adaptée au cas, préparez un nouveau fichier WXR valide pour le périmètre confirmé comme manquant ou repartez sur une destination de test remise à son état initial. Évitez de couper du XML à une ligne arbitraire. Les auteurs, les termes et les références de médias font partie du contexte de l’import. Après le premier petit lot, contrôlez une page, son auteur, ses liens et ses images. Si le résultat est cohérent, conservez le même mécanisme pour les lots suivants et notez chacun comme terminé avant d’en lancer un autre.
Réduire le périmètre d’un export depuis l’administration
Dans Outils puis Exporter, choisissez le type de contenu et les filtres disponibles pour cette source. Un export d’articles peut être réparti en périodes qui se suivent sans chevauchement selon les filtres proposés. Notez les bornes et le nombre de contenus attendus par période. Les mêmes filtres ne sont pas disponibles pour tous les types de contenu. Vérifiez le fichier obtenu pour chaque tranche et gardez son nom avec le périmètre qu’il représente. Cette méthode convient lorsque chaque tranche peut terminer dans la fenêtre du serveur et du proxy.
Avant d’utiliser les fichiers pour un import, vérifiez que l’ensemble couvre le besoin. Le format WXR transporte du contenu et des références. Les fichiers de médias et les réglages du site demandent une vérification propre à la migration. Pour une tranche qui échoue encore, rapprochez l’heure des journaux et cherchez un contenu ou un média qui bloque à l’intérieur de ce périmètre. Diminuer la tranche aide à localiser l’étape, mais peut laisser le même élément problématique. Conservez la tranche refusée et son journal au lieu de multiplier des exports dont le recouvrement devient difficile à suivre.
Préparer l’export depuis le terminal existant
Si le site dispose déjà de WP-CLI et d’un accès terminal autorisé, un export en ligne de commande évite le délai de cette demande web. Vérifiez d’abord le serveur, le dossier WordPress et le site ciblé. La commande ci-dessous est un exemple à adapter dans le terminal du mainteneur. Remplacez le chemin et le répertoire de sortie par des emplacements vérifiés de votre installation. Préparez un répertoire privé accessible à ce compte et disposant d’assez d’espace. Dans un réseau multisite, ajoutez l’URL du sous-site voulu selon la procédure de ciblage de l’équipe.
L’option max_file_size de wp export limite la taille visée des fichiers WXR en mégaoctets et peut produire plusieurs fichiers. Elle ne fixe pas le temps d’exécution d’une requête ni la taille d’un média. Gardez tous les fichiers produits et les informations de fin de commande. Vérifiez la liste des contenus et faites un import de contrôle sur la copie avant de traiter l’ensemble. Les limites du processus PHP en terminal, les ressources disponibles et les lectures distantes restent à surveiller. Un autre trajet d’exécution demande toujours une validation du contenu obtenu.
wp --path=/chemin/verifie/wordpress export --dir=/repertoire/prive/exports --max_file_size=10Choisir un traitement avec un état consultable
Pour une intégration maintenue par votre équipe qui doit régulièrement traiter de grands volumes, préparez des lots limités et un état de progression consultable. Le navigateur lance une tâche, reçoit son identifiant puis consulte des demandes courtes de suivi. L’opération de fond conserve la liste des éléments terminés et la prochaine étape. Le mainteneur doit définir ce qui se passe après une interruption et comment une nouvelle demande reconnaît un travail déjà lancé. C’est un changement du fonctionnement de l’outil, à tester sur une copie avec un lot représentatif.
Si l’importeur possède déjà ce mécanisme, vérifiez le déclencheur de ses tâches et le journal de la file. Une erreur sur l’écran de suivi ne signifie pas que le travail a cessé. À l’inverse, une file affichée sans progression demande de vérifier son exécution. Conservez un identifiant stable pour rapprocher l’écran et le journal. Le résultat attendu est une opération qui peut être observée, interrompue selon la méthode prévue et reprise sans rejouer les éléments terminés. Une simple réponse « démarré » doit être suivie d’un résultat de fin que l’équipe peut contrôler.
Évaluer un trajet différent avec le responsable d’hébergement
La documentation Cloudflare présente aussi des possibilités propres aux traitements longs et à certaines offres, dont un sous-domaine sans proxy ou une adaptation de limite sur une offre qui la prend en charge. Ces choix demandent l’intervention du responsable du domaine et de l’origine. Une adresse administrative séparée doit garder une protection adaptée, un certificat valable et les règles d’accès nécessaires. Faites confirmer le trajet avant de modifier une zone ou de transmettre un secret. Le délai d’un autre serveur situé devant PHP peut encore s’appliquer.
Pour une opération ponctuelle, le terminal déjà autorisé ou un fractionnement contrôlé peut suffire. Pour un besoin récurrent, le suivi asynchrone peut être plus adapté. Choisissez selon les accès et le travail réellement en cause. Si la lenteur vient d’une requête de base ou d’un média distant, traitez également cette étape. Une fenêtre plus longue peut permettre à un processus coûteux de finir tout en maintenant une charge excessive. Conservez la limite d’origine et la procédure de retour pour tout changement que l’exploitant jugera nécessaire.
Rétablir les données et réglages concernés
Un export qui échoue peut laisser un fichier incomplet. Gardez l’original reçu comme preuve, puis conservez séparément le fichier valide obtenu par le nouveau trajet. Avant de retirer un fichier de sortie privé, vérifiez qu’aucune étape de migration ne le référence encore. Pour un import partiel, utilisez la liste des éléments créés ou modifiés afin de préparer le retour ciblé sur la copie. Si l’importeur offre un journal d’annulation, vérifiez son périmètre et ses limites avant de l’appliquer.
Une restauration de toute la base remettrait également les commandes, inscriptions et contenus récents à une date antérieure. Faites établir leur conservation si un tel retour est envisagé sur le site actif. Un changement de délai, de mode d’exécution ou de réglage d’import a son propre retour. Restaurez sa valeur précédente puis vérifiez la page publique et l’accès administratif. Si un travail de fond est encore actif, utilisez son mécanisme d’arrêt documenté avant de lancer une reprise depuis un autre état. Deux traitements sur le même lot peuvent rendre le bilan impossible à interpréter.
Valider le lot et les effets qui l’accompagnent
Préparez un inventaire avec les éléments attendus et les valeurs qui permettent de les reconnaître. Contrôlez le début, la fin et un exemple de chaque type de contenu ou de média. Pour une mise à jour, vérifiez une valeur modifiée et une valeur qui devait être conservée. Les comptes globaux aident à repérer un écart, puis les identifiants permettent de l’expliquer.
- Vérifiez que le travail initial est terminé ou arrêté selon la procédure de l’outil.
- Comparez les éléments traités au périmètre du fichier et aux réglages conservés.
- Vérifiez une création, une mise à jour et les associations d’auteurs ou de médias attendues.
- Contrôlez les fichiers d’export avec un import de test sur une copie préparée.
- Vérifiez les éventuels effets externes dans leur environnement de test et rapprochez leurs identifiants.
- Consignez les lots terminés, ceux à reprendre et le point de restauration à utiliser pour annuler la seule opération concernée.
Conserver un scénario de contrôle pour le prochain volume
Gardez la taille du lot, son type, la durée observée et le trajet d’exécution validé. Ajoutez le propriétaire de l’outil, l’endroit où lire sa progression et la méthode qui reconnaît un élément déjà traité. Le prochain incident pourra commencer par ces repères. Après une modification d’importeur ou d’hébergement, reprenez un petit lot avec une création et un élément existant. Vérifiez que le mécanisme de reprise conserve son comportement.
Cloudflare et WP-CLI apportent des informations à des étapes différentes. Le premier signale le délai de la demande proxifiée. Le second offre un trajet d’export quand l’équipe dispose déjà du terminal. Une extension supplémentaire n’est utile que si elle fournit réellement la reprise ou le suivi nécessaire et si son format correspond au besoin. Gardez les conditions de l’offre et les limites vérifiées dans le bilan technique de votre site. Le critère de fin reste le contenu obtenu et les effets attendus, avec un état explicite pour chaque lot.
