Le client, une marque de cosmétiques vendant en ligne, avait une charte graphique précise — une palette de trois couleurs et deux typographies bien définies — mais sa page produit WooCommerce continuait d’afficher les couleurs par défaut du thème, en décalage complet avec le reste du site construit à partir de blocs. Plutôt que d’ajouter une surcharge CSS spécifique à chaque bloc du gabarit produit, ce qui aurait créé une dette de maintenance à chaque mise à jour de thème, la démarche retenue s’est appuyée entièrement sur les classes globales définies dans theme.json. Ce tutoriel ne couvre pas l’éditeur V4 d’Elementor, hors périmètre ici puisque le projet reposait sur un thème de blocs natif WordPress.
Étape 1 : cartographier les couleurs existantes du thème
Avant de modifier quoi que ce soit, il faut identifier les palettes déjà déclarées par le thème actif dans son propre theme.json, généralement visibles dans la section settings.color.palette. Un thème de blocs bien construit expose ses couleurs sous forme de variables nommées (--wp--preset--color--nom-couleur), que l’éditeur de site propose ensuite dans son sélecteur de couleurs sous forme de pastilles nommées.
Étape 2 : étendre la palette via un theme.json enfant
Plutôt que de modifier directement le thème parent, ce qui serait écrasé à la moindre mise à jour, la palette du client a été ajoutée dans le theme.json d’un thème enfant, en complément des couleurs existantes plutôt qu’en remplacement complet, pour ne pas casser d’éventuels blocs déjà configurés ailleurs sur le site avec les couleurs d’origine.
{
"version": 2,
"settings": {
"color": {
"palette": [
{
"slug": "rose-signature",
"color": "#c9435a",
"name": "Rose signature"
},
{
"slug": "vert-sauge",
"color": "#7a8f6e",
"name": "Vert sauge"
}
]
},
"typography": {
"fontFamilies": [
{
"slug": "titre-marque",
"fontFamily": "\"Fraunces\", serif",
"name": "Titre de marque"
}
]
}
}
}
Étape 3 : créer les classes globales dérivées
Chaque couleur et typographie déclarée dans theme.json génère automatiquement des classes utilitaires exploitables directement dans le HTML des blocs, sans écrire une seule ligne de CSS personnalisée : has-rose-signature-color, has-rose-signature-background-color, has-titre-marque-font-family. C’est ce mécanisme, natif à WordPress depuis l’arrivée de theme.json, qui a permis d’appliquer la charte graphique directement depuis l’interface de l’éditeur de site, bloc par bloc, sans code additionnel.
Étape 4 : appliquer les classes au gabarit de la page produit
Le gabarit de page produit WooCommerce, lorsqu’il est construit avec les blocs WooCommerce natifs (Titre du produit, Prix du produit, Galerie du produit), reste modifiable depuis l’éditeur de site comme n’importe quel autre gabarit de blocs. Chaque bloc de titre a reçu la classe de typographie de marque via le panneau de style de l’éditeur, chaque bouton d’ajout au panier a reçu la couleur de fond correspondant à la palette du client, directement depuis les contrôles visuels de l’éditeur, sans toucher au code du thème parent.
Le piège des blocs WooCommerce qui n’héritent pas tout
Un point a surpris l’équipe en cours de projet : certains blocs WooCommerce, notamment ceux liés au prix barré en cas de promotion, appliquent leurs propres styles par défaut via une feuille de style embarquée par l’extension, qui peut entrer en conflit de spécificité CSS avec les classes globales issues de theme.json. Il a fallu, dans ce cas précis, ajouter une règle CSS ciblée dans les styles additionnels du thème, en s’appuyant toujours sur la variable de couleur globale plutôt que sur une valeur hexadécimale codée en dur, pour que la couleur reste centralisée même dans ce cas particulier.
.wc-block-components-product-price del {
color: var(--wp--preset--color--vert-sauge);
}Ce que cette approche évite
- Une multiplication de règles CSS ad hoc dispersées dans un fichier de styles additionnels difficile à maintenir dans le temps.
- Une couleur codée en dur à plusieurs endroits différents, qui obligerait à modifier chaque occurrence manuellement le jour où la charte graphique évolue.
- Une incohérence visuelle entre les pages de contenu classique du site, déjà construites avec les classes globales, et la page produit qui serait restée à l’écart de ce système.
Le jour où le client change une seule couleur de sa charte, la modification tient en une ligne dans
theme.json. C’est ce test, plus que n’importe quelle démonstration visuelle, qui convainc qu’une architecture de style est bien pensée.
En résumé
Personnaliser une page produit WooCommerce pour qu’elle respecte une charte graphique précise ne demande pas de surcharge CSS extensive dès lors que le thème s’appuie sur theme.json et ses classes globales : étendre la palette et la typographie dans un thème enfant, appliquer les classes via l’éditeur de site, et ne recourir à du CSS ciblé qu’en dernier recours pour les blocs qui n’héritent pas correctement du système global. Cette discipline garantit une charte graphique centralisée en un seul endroit, modifiable sans jamais toucher au gabarit lui-même.
