Un thème bloc, contrairement à un thème classique, expose une grande partie de sa configuration dans un fichier theme.json et dans des patterns réutilisables, deux surfaces que les clients personnalisent souvent directement depuis l’éditeur de site sans jamais toucher au code. Une mise à jour qui écrase ces personnalisations, même involontairement, se traduit immédiatement par une réclamation client, contrairement à un bug caché dans une fonction PHP que personne ne remarque avant longtemps. Voici la checklist que nous suivons avant chaque publication d’une nouvelle version de notre thème bloc parent, partagé par dix-huit sites clients.
1. Valider le schéma de theme.json avant toute autre vérification
Une erreur de syntaxe ou une clé mal orthographiée dans theme.json ne provoque pas toujours une erreur fatale visible : WordPress ignore parfois silencieusement une section malformée, ce qui se traduit par une perte de fonctionnalité sans message d’erreur. On valide systématiquement contre le schéma officiel avant toute autre étape :
npx ajv-cli validate -s https://schemas.wp.org/trunk/theme.json -d theme.json
2. Vérifier que les patterns survivent à une réactivation du thème
Les patterns enregistrés côté thème peuvent entrer en conflit avec des patterns identiques enregistrés côté extension ou côté thème enfant, en particulier si un client a dupliqué un pattern pour le personnaliser. On teste ce scénario précis :
- Activer un autre thème temporairement.
- Réactiver le thème bloc mis à jour.
- Vérifier via
wp_get_registered_block_patterns()qu’aucun pattern du thème ne remplace silencieusement une version personnalisée par le client, en particulier si les deux partagent le même identifiant.
3. Ne jamais écraser les styles globaux personnalisés par le client
Les réglages de styles globaux modifiés depuis l’éditeur de site sont stockés dans une entrée de type wp_global_styles, distincte du fichier theme.json du thème. Une mise à jour du thème ne doit jamais réinitialiser cette entrée. On vérifie ce point en modifiant volontairement une couleur d’accent depuis l’éditeur de site avant la mise à jour, puis en confirmant après mise à jour que ce réglage personnalisé est toujours actif :
wp post list --post_type=wp_global_styles --field=ID
wp post get 123 --field=post_content | grep -o '"color":{"palette"[^}]*}'4. Vérifier chaque template dans l’éditeur de site, pas seulement en front
Un template modifié côté code peut s’afficher correctement en front tout en cassant l’édition visuelle dans l’éditeur de site, notamment si un bloc utilisé n’est plus enregistré ou a changé de nom. On ouvre systématiquement chaque template concerné (index, single, archive, 404) dans l’éditeur avant de considérer la mise à jour prête.
5. Rejouer les tests automatisés existants sur un site de démonstration réaliste
Un site de test vide masque des problèmes qui n’apparaissent qu’avec du contenu réel : longs titres, images en portrait, articles sans image mise en avant. Notre suite Playwright s’exécute sur un site de démonstration maintenu avec du contenu volontairement varié et imparfait, plus proche de la réalité qu’une installation fraîche.
6. Vérifier la compatibilité ascendante des noms de blocs et de styles
- Un style de bloc renommé (
register_block_style) casse silencieusement l’affichage de tout contenu existant qui référence l’ancien nom. - Une variation de bloc supprimée doit être conservée en alias au minimum une version, avec dépréciation documentée dans le changelog.
- Un pattern renommé doit rester accessible sous son ancien identifiant si des pages existantes en dépendent, via un mappage explicite plutôt qu’une suppression sèche.
7. Documenter et faire valider par un humain avant publication
Cette checklist ne remplace pas Theme Check, l’outil de vérification officiel des standards de thème, qui reste une étape distincte et complémentaire de contrôle de conformité technique. Elle porte spécifiquement sur les risques propres aux thèmes blocs, où la frontière entre code et personnalisation client est plus poreuse que sur un thème classique.
Pour aller plus loin
Chaque case cochée sur cette liste correspond à un incident réel vécu sur l’un des dix-huit sites clients partageant ce thème parent, ce qui explique sa longueur : elle n’est pas théorique, elle est le résultat direct de plusieurs mises à jour qui se sont mal passées avant sa mise en place.
