Une agence migrait le contenu d’un ancien site vers une nouvelle installation, en s’appuyant sur l’export WXR natif de WordPress puis sur l’import correspondant côté destination. Sur la centaine d’articles migrés, l’écrasante majorité s’est importée sans le moindre souci, mais une poignée d’entre eux affichait, une fois arrivés sur le nouveau site, un bloc « Citation mise en avant » totalement absent, comme s’il n’avait jamais existé, alors que l’article source le contenait bien visiblement.
Ce genre de perte partielle, touchant seulement certains articles et non tous, complique le diagnostic : la tentation est de chercher un problème d’extension manquante côté destination, alors que la cause réelle se situait dans l’export lui-même, au niveau de l’échappement des caractères spéciaux contenus dans les attributs du bloc.
Comment le format WXR encode le contenu
Le format d’export WXR est un fichier XML dans lequel le contenu de chaque article, delimiters de blocs compris, est encapsulé dans une section CDATA, un mécanisme XML qui permet d’inclure du texte brut sans que les caractères comme < ou & ne soient interprétés comme des balises XML.
<content:encoded><![CDATA[
<!-- wp:quote {"citation":"Un mot avec des guillemets"} -->
<blockquote><p>Un mot avec des guillemets</p></blockquote>
<!-- /wp:quote -->
]]></content:encoded>Le point de rupture : des guillemets dans les guillemets
Le problème apparaît quand un attribut du bloc contient lui-même une séquence de caractères qui ressemble à la fermeture de la section CDATA, la suite ]]>, ou quand l’export a été manipulé entre-temps par un outil tiers (un script de recherche-remplacement sur le fichier XML, par exemple) qui a mal géré l’échappement des guillemets doubles contenus dans le JSON du commentaire de bloc.
Sur le cas rencontré par l’agence, l’article fautif contenait une citation qui incluait elle-même des guillemets typographiques doubles, mal convertis lors d’un précédent import depuis un traitement de texte. Ces guillemets, une fois sérialisés dans l’attribut JSON du bloc puis réexportés en WXR, ont fini par casser la structure attendue à l’import, ce qui a conduit WordPress à ignorer purement et simplement le bloc concerné plutôt que de générer une erreur bloquante visible.
Pourquoi l’échec reste silencieux
L’importeur WXR privilégie la résilience à l’arrêt total : face à un bloc dont la structure JSON ne peut être correctement analysée, WordPress choisit de poursuivre l’import du reste de l’article en abandonnant simplement le contenu du bloc problématique, plutôt que de faire échouer l’import de l’article entier. Ce choix, raisonnable pour éviter qu’une seule anomalie ne bloque toute une migration, a pour revers de rendre la perte de contenu difficile à repérer sans une vérification systématique après import.
Comment vérifier après une migration
- Comparer le nombre de blocs d’un type donné entre le site source et le site de destination, via un script basé sur parse_blocks().
- Rechercher dans le fichier d’export WXR brut la présence de séquences suspectes comme des guillemets doubles non échappés à l’intérieur d’un attribut JSON de bloc.
- Ne jamais modifier un fichier WXR à la main avec un simple éditeur de texte sans connaître précisément l’encodage attendu par chaque section.
wp eval 'foreach ( get_posts( ["numberposts" => -1] ) as $p ) {
$blocs = parse_blocks( $p->post_content );
echo $p->ID . ": " . count( $blocs ) . " blocs\n";
}'Prévenir plutôt que corriger après coup
Pour un contenu contenant des guillemets typographiques ou des caractères spéciaux dans des attributs de bloc, privilégier une migration directe en base de données (export puis import SQL) plutôt qu’un passage par le format WXR réduit le risque d’échappement défaillant, puisque cette méthode ne traverse jamais la double couche d’encodage XML et JSON imbriquée qui a causé cet incident.
Un import WXR sans erreur affichée à l’écran ne garantit jamais un contenu intégralement préservé. Seule une vérification quantitative après import, bloc par bloc, permet de s’en assurer avec certitude.
Ce qu’il faut retenir
Cette perte silencieuse rappelle que la sérialisation de blocs en commentaires HTML, bien que robuste dans l’usage courant de l’éditeur, reste fragile face à des chaînes de traitement intermédiaires qui n’ont pas été conçues en connaissance de ce format. Un audit post-migration systématique, comparant le nombre de blocs avant et après, aurait permis de détecter ce cas en quelques minutes plutôt qu’au moment où un rédacteur a signalé l’absence de la citation sur le site en production.
