# Le tunnel de commande WooCommerce Blocks face à un CSS de thème hérité

> Reprendre un thème ancien et basculer sur les blocs Panier et Paiement change plus de choses qu'il n'y paraît côté styles. Voici ce qui casse le plus souvent et pourquoi.

- Auteur : Clément Hadrot
- Publié le : 2025-08-08
- Mis à jour le : 2025-08-08
- Catégorie : E-commerce
- URL : https://wpmoderne.dev.wordpress-developpement.fr/ecommerce/woocommerce-blocks-panier-paiement-css-theme-herite/

## L’essentiel

- Les blocs génèrent leur propre balisage, pas les gabarits classiques
- Les sélecteurs génériques du thème perdent leur cible
- Isoler les styles plutôt que les écraser un à un

Qu'est-ce qui distingue vraiment le panier classique de WooCommerce du bloc Panier introduit avec les blocs Panier et Paiement ? Le contenu affiché est presque identique, mais le balisage sous-jacent n'a rien à voir. C'est exactement ce que découvre un intégrateur chargé de reprendre un thème ancien, écrit avant l'arrivée de ces blocs, au moment de basculer le tunnel d'achat sur cette nouvelle version.

Le thème hérité cible des classes issues des anciens gabarits `cart.php` et `form-checkout.php`, comme `.woocommerce-cart-form` ou `#order_review`. Une fois les blocs activés, ces classes disparaissent tout simplement du balisage rendu, remplacées par une arborescence générée par React côté client et des classes préfixées `wc-block-`.

## Comprendre la nature du changement de balisage

Les gabarits classiques de WooCommerce sont des fichiers PHP inclus par le thème ou surchargés dans un dossier `woocommerce/` du thème enfant. Les blocs Panier et Paiement, eux, sont des blocs Gutenberg complets, insérés dans une page via l'éditeur de blocs, et rendus par un mélange de PHP côté serveur pour le premier affichage puis d'hydratation JavaScript pour l'interactivité, via l'Interactivity API stabilisée avec WordPress 6.5.

Concrètement, une page Panier construite avec les blocs ne contient plus `<table class="shop_table cart">` mais une structure de type `<div class="wp-block-woocommerce-cart-items-block">` imbriquant elle-même des blocs plus petits pour chaque ligne, chaque quantité, chaque sous-total. Un sélecteur CSS du thème hérité qui ciblait `.cart_item td.product-name` ne trouve tout simplement plus rien à styliser.

## Les styles génériques du thème qui posent le plus de problèmes

Trois catégories de règles CSS héritées causent l'essentiel des dégâts visuels observés lors d'une migration vers les blocs. D'abord les règles de mise en page basées sur des sélecteurs de tableau, comme `table.shop_table td`, qui n'ont plus de cible puisque les blocs n'utilisent plus de tableau HTML pour le panier. Ensuite les règles de bouton très génériques, du type `.woocommerce a.button`, qui continuent parfois de s'appliquer partiellement aux blocs mais avec des espacements incohérents car les blocs ajoutent leurs propres classes utilitaires d'espacement. Enfin les règles de formulaire ciblant `#billing_first_name` et consorts, des identifiants qui n'existent plus dans le bloc Paiement, remplacés par des champs gérés par le composant `CheckoutBlock`.

> L'essentiel à retenir : Les blocs génèrent leur propre balisage, pas les gabarits classiques ; Les sélecteurs génériques du thème perdent leur cible ; Isoler les styles plutôt que les écraser un à un

## Isoler plutôt qu'écraser : la bonne stratégie CSS

La tentation naturelle consiste à ajouter des règles `!important` pour forcer l'ancien style sur les nouvelles classes. C'est la voie la plus rapide vers un CSS ingérable en quelques semaines. La stratégie qui tient dans la durée consiste à traiter les blocs comme un système de styles à part entière, avec ses propres points d'entrée documentés.

### S'appuyer sur les classes stables exposées par les blocs

WooCommerce Blocks expose des classes stables destinées justement à la personnalisation par thème, comme `.wc-block-cart`, `.wc-block-checkout` ou `.wc-block-components-product-name`. Ce sont ces classes qu'il faut cibler dans le thème enfant, dans une feuille de styles dédiée plutôt que mélangée aux anciennes règles :

```
.wc-block-cart-item__wrap {
    padding: 1rem 0;
    border-bottom: 1px solid var(--couleur-bordure);
}

.wc-block-components-button {
    border-radius: 4px;
    font-weight: 600;
}
```

### Nettoyer avant d'ajouter

Avant d'ajouter la moindre nouvelle règle, il vaut mieux commenter temporairement les anciennes règles ciblant les gabarits classiques du panier et du paiement, page par page, pour observer ce qui reste réellement appliqué par erreur. Un audit rapide via les outils de développement du navigateur, en filtrant les règles CSS appliquées sur la page Panier, révèle souvent des dizaines de règles orphelines qui ne ciblent plus rien mais alourdissent encore la feuille de styles chargée.

## Le cas particulier des variables globales du thème

Si le thème hérité définit ses couleurs et espacements via des variables CSS personnalisées, ces variables restent utilisables dans les styles de blocs sans difficulté, puisque les blocs héritent du contexte CSS de la page comme n'importe quel autre élément. En revanche, un thème qui définissait ses couleurs uniquement via des classes utilitaires Sass compilées en amont, sans variables CSS exposées à l'exécution, devra d'abord extraire ces valeurs sous forme de propriétés personnalisées CSS avant de pouvoir les réutiliser proprement dans les styles ciblant les blocs.

## Notre verdict

Basculer un thème ancien vers les blocs Panier et Paiement n'est jamais un simple changement d'activation dans les réglages WooCommerce : c'est une réécriture partielle de la feuille de styles du tunnel d'achat. Le temps gagné à ne pas migrer les gabarits PHP se paie en travail de CSS ciblé sur les nouvelles classes stables. Mieux vaut budgétiser ce chantier dès le départ plutôt que de le découvrir en production après une bascule précipitée.