Texte du pied de page
``` Pourquoi c'est un problème : la couleur `#3a3a3a` n'existe dans aucun preset de `theme.json`. Le jour où le client demande d'assombrir légèrement sa charte, il faut rouvrir chaque template pour traquer les couleurs codées en dur, avec le risque d'en oublier une. Le système de design perd tout son intérêt : autant revenir à un thème classique avec une feuille CSS unique. Quoi faire : déclarer systématiquement la couleur en preset dans `theme.json`, puis référencer la classe générée (`has-pied-de-page-color` par exemple) plutôt que la valeur brute. Un script de recherche sur `style="color:` dans le dossier `templates` permet de faire le ménage sur un thème existant. ## Des templates dupliqués au lieu de template parts Second travers, très fréquent sur les sites avec plusieurs types de contenus : un template `single-evenement.html` et un template `single-formation.html` qui partagent 90 % de leur structure, mais ont été créés en dupliquant l'un depuis l'autre plutôt qu'en factorisant les blocs communs. > L'essentiel à retenir : Le CSS brut dans theme.json fait perdre l'intérêt du système de design ; Les templates dupliqués multiplient le coût de maintenance ; Les patterns non traduisibles bloquent les sites multilingues Pourquoi c'est un problème : chaque correctif — un changement de mise en page dans l'en-tête d'article, un ajustement du fil d'Ariane — doit être répété dans chaque fichier dupliqué. Sur un projet avec cinq types de contenus proches, nous avons vu des templates diverger silencieusement au fil des interventions, jusqu'à ce que deux pages du même site n'affichent plus la même structure sans que personne ne l'ait décidé. Quoi faire : extraire la structure commune dans un `template-part` dédié (via `register_block_template` ou simplement un fichier dans `parts/`), et ne garder dans chaque template spécifique que ce qui diffère réellement — souvent une simple requête de champs personnalisés. ## theme.json surchargé de CSS brut Troisième travers : un fichier `theme.json` qui ne contient presque aucun preset, mais renvoie l'essentiel du style vers une feuille `style.css` classique bourrée de sélecteurs très spécifiques, du type `.wp-block-group.is-style-carte > .wp-block-heading`. | Approche | Conséquence | | --- | --- | | Presets dans theme.json | Valeurs disponibles dans l'éditeur, cohérentes, faciles à faire évoluer globalement | | CSS brut avec sélecteurs spécifiques | Valeurs invisibles pour l'éditeur, risque de conflits de spécificité, maintenance dispersée entre deux fichiers | Ce n'est pas que le CSS classique soit interdit dans un thème bloc : certains ajustements fins (grilles complexes, animations) n'ont pas d'équivalent dans `theme.json`. Le problème survient quand le CSS reprend la main sur des décisions qui relèvent du design system — couleurs, espacements, typographie — et que ces décisions deviennent invisibles pour l'éditeur de site. ## Des patterns non traduisibles Dernier travers, plus discret mais coûteux sur les sites multilingues : des patterns enregistrés en PHP avec du texte codé en dur, sans passer par les fonctions de traduction de WordPress. ``` register_block_pattern( 'mon-theme/hero-accueil', array( 'title' => 'Bloc héros accueil', 'content' => 'Bienvenue chez nous
', ) ); ``` Pourquoi c'est un problème : le texte « Bienvenue chez nous » est figé dans le code PHP. Sur un site utilisant Polylang ou WPML, ce pattern ne sera jamais traduit automatiquement, contrairement au contenu saisi directement dans l'éditeur. Le client se retrouve avec un pattern qu'il doit modifier manuellement à la main dans chaque langue, ou pire, qu'il n'ose pas toucher de peur de casser la mise en forme. Quoi faire : entourer chaque chaîne de `esc_html__()` ou `__()` avec le bon domaine de texte, y compris dans le contenu HTML injecté par le pattern. Le titre et la description du pattern lui-même, affichés dans l'inserteur de blocs, doivent aussi passer par ces fonctions. ## En résumé Ces quatre anti-patterns partagent un point commun : ils apparaissent presque toujours sous la pression du délai, quand il est plus rapide de coder en dur une valeur que de la déclarer proprement dans le système de design. Le coût se paie ensuite, en maintenance, souvent par une autre personne que celle qui a écrit le code initial. Un audit rapide en fin de projet — recherche de styles inline, de templates trop proches, de CSS non justifié et de chaînes non traduites — suffit à repérer l'essentiel avant la livraison.