Un client e-commerce m’a contacté un lundi matin après avoir migré son site vers un nouvel hébergeur via un export-import classique par plugin. Tout semblait fonctionner à première vue : les pages s’affichaient, les produits étaient là. Mais en ouvrant l’éditeur de site pour une modification mineure, l’onglet Patterns de la bibliothèque, section « Mes patterns », s’affichait complètement vide, alors que le site en comptait plusieurs dizaines avant la migration.
Ce type d’incident, silencieux comme souvent en matière de FSE, m’a demandé une vingtaine de minutes d’investigation avant de comprendre exactement ce qui s’était passé pendant l’import.
Comprendre ce que sont réellement les patterns personnalisés
Un point essentiel à vérifier en premier : les patterns personnalisés créés depuis l’éditeur (contrairement aux patterns enregistrés en PHP par un thème via register_block_pattern()) sont stockés en base de données comme des posts de type wp_block, au même titre qu’un article ou une page. Ils sont donc soumis aux mêmes mécanismes d’import, d’export et de statut de publication que n’importe quel contenu.
Diagnostic : les patterns existaient toujours, en statut brouillon
Une requête directe en base, via WP-CLI, a permis de vérifier immédiatement si les patterns avaient réellement disparu ou s’ils existaient encore sous un statut différent :
wp post list --post_type=wp_block --post_status=any --field=ID,post_title,post_status --format=tableLe résultat a été rassurant sur le principe et frustrant sur le fond : les trente-quatre patterns personnalisés du client étaient bien présents dans la base migrée, mais tous en statut draft plutôt que publish. Or l’éditeur de site, dans son onglet Patterns, n’affiche par défaut que les patterns publiés, ce qui explique la bibliothèque apparemment vide malgré des données intactes.
Comprendre pourquoi le statut avait changé pendant l’import
En creusant la configuration du plugin d’export-import utilisé pour la migration, j’ai trouvé la cause précise : l’outil appliquait par défaut un statut draft à tout contenu importé dont l’auteur d’origine ne correspondait à aucun utilisateur existant sur le nouvel hébergement, par mesure de prudence pour éviter une publication accidentelle de contenu orphelin. Les patterns, créés à l’origine par un compte utilisateur supprimé entre-temps sur l’ancien site, sont tombés dans ce cas précis.
Correctif : republier en masse via WP-CLI
Plutôt que de rouvrir et republier manuellement trente-quatre patterns un par un, une commande WP-CLI a permis de corriger le statut en une seule opération, après validation visuelle rapide du contenu de chacun pour écarter tout pattern réellement obsolète parmi le lot :
wp post list --post_type=wp_block --post_status=draft --field=ID | \
xargs -I {} wp post update {} --post_status=publishAprès exécution, l’onglet Patterns de l’éditeur de site a immédiatement réaffiché l’intégralité de la bibliothèque, sans qu’aucune donnée n’ait eu besoin d’être recréée depuis une sauvegarde.
Vérifier l’auteur avant republication
Avant de republier, j’ai également réattribué ces patterns à un compte administrateur actif sur le nouvel hébergement, via wp post update {} --post_author=1, pour éviter qu’un futur export ne retombe dans le même piège à cause d’un identifiant d’auteur orphelin.
Prévention pour les prochaines migrations
- Vérifier systématiquement les statuts de tous les types de contenu après un import, pas uniquement les articles et pages visibles au premier coup d’œil.
- Contrôler la correspondance des identifiants d’auteur avant d’exporter un site, en particulier si des comptes ont été supprimés depuis la création du contenu.
- Préférer, quand c’est possible, un export via WP-CLI (
wp export) plutôt qu’un plugin tiers, pour un contrôle plus fin du comportement d’import.
Un contenu qui « disparaît » après une migration n’est presque jamais supprimé : il change le plus souvent de statut ou d’auteur, silencieusement, selon les règles de prudence de l’outil de migration utilisé.
En résumé
Les patterns personnalisés étant de simples posts wp_block, ils héritent de tous les comportements d’import et d’export standards de WordPress, y compris les changements de statut liés à des règles de prudence sur l’auteur d’origine. Une vérification en base via WP-CLI, avant de conclure à une perte de données, évite bien des reconstructions inutiles après une migration qui s’est en réalité bien déroulée sur le fond.
