Un pattern devenu obsolète après une mise à jour de bloc natif

Je gère la maintenance d’un parc d’une quarantaine de sites pour plusieurs clients d’une même agence partenaire, tous construits sur une base de thème bloc commune avec des patterns partagés. Après une mise à jour mineure de WordPress début mars, un client m’a signalé qu’un bloc « avant-après » utilisé sur une dizaine de pages produit affichait désormais les deux images l’une en dessous de l’autre au lieu de côte à côte, sans qu’aucune modification n’ait été apportée au contenu lui-même.

Ce type d’incident, provoqué non pas par une action humaine mais par un changement de comportement par défaut d’un bloc natif entre deux versions mineures, méritait une méthode de détection systématique plutôt qu’une correction au cas par cas sur chaque site concerné.

Comprendre pourquoi un pattern peut se casser sans qu’on y touche

Un pattern enregistré, qu’il soit synchronisé ou non, stocke un balisage de blocs figé au moment de sa création, avec les attributs alors valides pour chaque bloc utilisé. Si une mise à jour du cœur WordPress modifie la valeur par défaut d’un attribut non explicitement défini dans ce balisage enregistré, le rendu peut changer sans qu’aucune ligne du pattern lui-même n’ait été modifiée : c’est la valeur par défaut appliquée par le bloc qui a évolué, pas le contenu stocké.

Diagnostic : retrouver l’attribut concerné

En comparant le balisage du pattern « avant-après », construit sur un Groupe en disposition flex, avec la documentation des changements de la version concernée, la cause est apparue : le bloc Groupe ne déclarait pas explicitement l’attribut flexWrap dans le pattern d’origine, écrit plusieurs années auparavant. La valeur par défaut de cet attribut, jusque-là nowrap de façon implicite, avait changé de comportement de rendu suite à un correctif du cœur touchant la disposition flex sur petits conteneurs.

<!-- wp:group {"layout":{"type":"flex"}} -->
<div class="wp-block-group">
  ...images avant-après...
</div>
<!-- /wp:group -->

Le correctif a consisté à rendre explicite l’attribut auparavant implicite, en rouvrant le pattern dans l’éditeur, en fixant manuellement flexWrap sur nowrap dans l’inspecteur, puis en sauvegardant la nouvelle version, ce qui fige désormais le comportement indépendamment des futures évolutions de la valeur par défaut du bloc.

<!-- wp:group {"layout":{"type":"flex","flexWrap":"nowrap"}} -->

Vérifier l’ampleur du problème sur tout le parc

Avant de corriger un seul site, j’ai voulu mesurer combien de sites du parc partageaient ce même pattern non explicite. Une recherche du motif "type":"flex" sans flexWrap associé, menée via un export de base de données de chaque site suivi d’une recherche par expression régulière, a permis d’identifier sept sites sur les quarante gérés utilisant une version non corrigée du pattern.

for site in $(cat liste-sites.txt); do
  wp --path="/var/www/${site}" db query \
    "SELECT ID FROM wp_posts WHERE post_type='wp_block' AND post_content LIKE '%\"type\":\"flex\"%' AND post_content NOT LIKE '%flexWrap%'"
done

Corriger les sept sites en une passe groupée

Plutôt que de rouvrir chaque pattern manuellement sur les sept sites, une petite routine WP-CLI a permis d’appliquer un remplacement de chaîne ciblé directement en base, après validation sur un environnement de test que le remplacement ne cassait aucun autre usage du même motif flex ailleurs dans le contenu.

Mettre en place une détection préventive

Pour éviter de découvrir ce type de régression via un signalement client, j’ai ajouté un contrôle visuel automatisé mensuel sur l’ensemble du parc, avec des captures d’écran comparées d’un mois sur l’autre sur les pages contenant les patterns partagés les plus utilisés. Un écart de rendu significatif entre deux captures déclenche une alerte, avant qu’un client ne le remarque lui-même.

• Déclarer explicitement les attributs de disposition dans tout pattern destiné à être réutilisé sur plusieurs sites.
• Mettre en place une comparaison visuelle automatisée avant et après chaque mise à jour mineure du cœur, sur un environnement de test.
• Documenter, pour chaque pattern partagé, la version de WordPress avec laquelle il a été validé pour la dernière fois.

Un pattern qui fonctionne aujourd’hui n’est jamais une garantie qu’il fonctionnera identiquement après la prochaine mise à jour mineure, tant que des attributs de rendu restent implicites plutôt qu’explicitement figés dans le balisage enregistré.

En résumé

Un pattern qui cesse de s’afficher correctement après une mise à jour du cœur ne signale pas nécessairement une régression du cœur lui-même, mais souvent un attribut resté implicite dans un balisage ancien, dont la valeur par défaut a évolué. Rendre explicites les attributs de disposition sensibles dans tout pattern partagé sur un parc de sites reste la meilleure protection contre ce type de régression silencieuse.