# WordPress 6.6 et les blocs Panier et Paiement : ce qui change pour WooCommerce

> À l'approche de la sortie de WordPress 6.6, la RC2 en cours de test révèle plusieurs évolutions à surveiller pour les personnalisations de blocs Panier et Paiement.

- Auteur : Clément Hadrot
- Publié le : 2024-06-22
- Mis à jour le : 2024-06-22
- Catégorie : E-commerce
- URL : https://wpmoderne.dev.wordpress-developpement.fr/ecommerce/wordpress-66-blocs-panier-paiement-woocommerce/

## L’essentiel

- La RC2 confirme deux changements dans le rendu des blocs Panier et Paiement
- Les slots d'extension existants restent compatibles, sans rupture annoncée
- Un correctif de rendu affecte les blocs enfants personnalisés dans certains thèmes

La release candidate 2 de WordPress 6.6, dont la sortie stable est prévue pour la mi-juillet, vient de sortir en test. Pour une équipe qui personnalise depuis plus d'un an les blocs Panier et Paiement de WooCommerce via des slots d'extension et l'Interactivity API, chaque cycle de bêta et de RC est l'occasion d'un audit de compatibilité avant la sortie stable.

La méthode suivie sur ce projet : installer la RC directement sur un environnement de recette isolé, rejouer l'ensemble des personnalisations de blocs, et documenter tout écart de comportement avant que la version ne devienne stable et n'atteigne les sites en production.

## Changement confirmé n°1 : le rendu des blocs enfants imbriqués

La RC2 modifie légèrement la façon dont l'éditeur de blocs gère l'imbrication de blocs enfants personnalisés à l'intérieur d'un bloc parent natif comme le bloc Paiement. Un bloc enfant ajouté via un slot d'extension (`registerCheckoutBlock`) qui reposait sur un ordre d'affichage implicite se retrouvait, en RC2, positionné différemment dans certains thèmes utilisant des styles globaux personnalisés poussés en théorie de manière compatible avec les versions précédentes.

```
registerCheckoutBlock( {
    metadata: {
        name: 'mon-plugin/bloc-fidelite',
        parent: [ 'woocommerce/checkout-fields-block' ],
    },
    component: BlocFidelite,
} );
```

Le correctif appliqué a consisté à préciser explicitement l'ordre d'affichage via l'attribut `order` dans les métadonnées du bloc, plutôt que de dépendre de l'ordre d'enregistrement implicite, qui n'était de toute façon jamais garanti de façon contractuelle par l'API.

## Changement confirmé n°2 : l'hydratation Interactivity API des fragments

> L'essentiel à retenir : La RC2 confirme deux changements dans le rendu des blocs Panier et Paiement ; Les slots d'extension existants restent compatibles, sans rupture annoncée ; Un correctif de rendu affecte les blocs enfants personnalisés dans certains thèmes

Le second changement observé en RC2 concerne l'hydratation des composants utilisant l'Interactivity API, stable depuis WordPress 6.5, à l'intérieur du mini-panier. Un composant personnalisé affichant un compteur de points de fidélité, qui s'appuyait sur une re-hydratation déclenchée par un événement DOM personnalisé, cessait de se mettre à jour correctement après un ajout au panier en RC2, le cycle d'hydratation ayant légèrement changé d'ordre par rapport à la version stable précédente.

Le correctif temporaire a consisté à migrer l'écoute d'événement vers le store natif de l'Interactivity API plutôt que vers un événement DOM personnalisé, une pratique de toute façon recommandée par la documentation officielle et plus robuste face à ce type d'évolution interne :

```
import { store, getContext } from '@wordpress/interactivity';

store( 'mon-plugin/fidelite', {
    callbacks: {
        surMiseAJourPanier: () => {
            const contexte = getContext();
            contexte.points = contexte.points + 1;
        },
    },
} );
```

## Ce qui reste stable

Rassurant pour la suite du projet : les slots d'extension eux-mêmes (`registerCheckoutBlock`, `registerCheckoutFilters`), cœur de la personnalisation des blocs Panier et Paiement, n'ont montré aucun changement de comportement en RC2. Seuls des effets de bord liés à l'ordre de rendu et à l'hydratation ont été identifiés, pas de rupture d'API annoncée pour cette version.

- Tester chaque bloc personnalisé sur la RC avant la sortie stable, pas seulement au moment de la mise à jour effective.
- Vérifier l'ordre d'affichage des blocs enfants imbriqués dans le bloc Paiement.
- Contrôler l'hydratation de tout composant Interactivity API qui dépend d'un événement DOM personnalisé plutôt que du store natif.

> Conseil maison : testez systématiquement vos blocs personnalisés WooCommerce sur chaque release candidate de WordPress, pas seulement sur la version stable finale. Les changements de comportement les plus subtils, ceux qui ne cassent rien de façon spectaculaire, se corrigent bien plus facilement avant la sortie générale qu'après.

## En résumé

La RC2 de WordPress 6.6 introduit deux ajustements de rendu qui touchent les personnalisations avancées des blocs Panier et Paiement, sans remettre en cause l'API d'extension elle-même. La découverte des blocs Panier et Paiement pour un développeur qui les aborderait pour la première fois n'est pas l'objet de cet article, centré sur le suivi de compatibilité d'une personnalisation déjà en production.