# WooCommerce 6.0 à 7.0 : les nouveautés qui comptent pour les développeurs

> Entre la 6.0 et la 6.6, WooCommerce a changé plus de choses côté code que côté interface. Un classement par impact réel, pour planifier une montée de version sans surprise.

- Auteur : Clément Hadrot
- Publié le : 2022-08-04
- Mis à jour le : 2022-08-04
- Catégorie : E-commerce
- URL : https://wpmoderne.dev.wordpress-developpement.fr/ecommerce/woocommerce-6-vers-7-nouveautes-developpeurs/

## L’essentiel

- L'API REST legacy v1 et v2 disparaît en 6.6, pas la v3
- Le stockage de commandes en tables dédiées avance en coulisses
- La majorité des changements 6.x restent invisibles côté thème

Depuis la sortie de la version 6.0 fin 2021, WooCommerce enchaîne les mises à jour mensuelles avec une régularité qui peut donner le vertige à qui doit planifier une montée de version sur un parc de sites clients. La tentation est grande de reporter la mise à jour « en attendant que ça se stabilise », mais certains changements de ce cycle 6.x méritent une attention immédiate, quand d'autres peuvent sans risque attendre la prochaine fenêtre de maintenance.

Ce classement n'a pas vocation à lister l'intégralité du changelog, disponible dans le fichier `changelog.txt` de chaque version, mais à distinguer ce qui casse réellement du code existant, ce qui mérite une vérification, et ce qui ne concerne que l'interface d'administration.

## Impact fort : la disparition de l'API REST legacy

Le changement le plus structurant de ce cycle concerne l'API REST. Les versions historiques `v1` et `v2`, héritées de l'époque où WooCommerce s'appelait encore une simple extension e-commerce sans API moderne, ont été retirées à l'occasion de la version 6.6. Seule la `v3`, disponible depuis WooCommerce 3.0 et déjà largement adoptée, subsiste. Pour une intégration tierce encore construite sur ces anciens points d'accès, dont l'URL commençait par `/wc-api/v2/` plutôt que `/wp-json/wc/v3/`, la mise à jour vers la 6.6 provoque un arrêt pur et simple des appels, sans message d'erreur explicite côté client si celui-ci ne journalise pas les codes de retour HTTP.

- Vérifier, avant toute montée vers la 6.6, les journaux serveur à la recherche d'appels vers `/wc-api/v1/` ou `/wc-api/v2/`.
- Migrer ces intégrations vers la v3, dont la structure de réponse JSON diffère sensiblement, notamment sur la représentation des variations de produit.
- Prévenir les prestataires tiers connectés (comparateurs de prix, places de marché) avant la fenêtre de mise à jour, pas après.

## Impact moyen : la maturation du stockage de commandes en coulisses

> L'essentiel à retenir : L'API REST legacy v1 et v2 disparaît en 6.6, pas la v3 ; Le stockage de commandes en tables dédiées avance en coulisses ; La majorité des changements 6.x restent invisibles côté thème

Le chantier du stockage haute performance des commandes, annoncé en 6.0 sous une forme encore expérimentale, continue d'avancer à chaque version sans être activé par défaut sur ce cycle 6.x. Il ne s'agit pas encore d'une bascule de production recommandée, mais chaque version 6.x apporte des ajustements internes à la façon dont les commandes sont lues et écrites, ce qui rend prudent de tester tout code personnalisé manipulant directement la table `wp_posts` pour les commandes plutôt que les fonctions `wc_get_order()` et la classe `WC_Order`. Ce découplage progressif de l'implémentation de stockage est justement ce qui rendra la future bascule possible sans casser les extensions correctement écrites.

## Impact moyen : les blocs Panier et Paiement gagnent en maturité

Les blocs Panier et Paiement, disponibles en option depuis un moment via l'extension WooCommerce Blocks, continuent de se stabiliser à chaque version du cycle 6.x, avec une couverture croissante des cas particuliers : coupons, méthodes de livraison multiples, champs de paiement personnalisés. Les thèmes et extensions qui personnalisent le tunnel de commande via les gabarits PHP classiques (`cart.php`, `checkout/form-checkout.php`) restent pleinement fonctionnels sur ce cycle, ces blocs demeurant une alternative activée par choix plutôt qu'un remplacement imposé.

## Impact faible : les ajustements d'interface d'administration

Une bonne partie des notes de version 6.x concerne des améliorations de l'écran « Rapports » et du tableau de bord d'accueil, ainsi que des corrections d'accessibilité sur les formulaires d'administration. Ces changements n'affectent ni le comportement de la boutique côté visiteur, ni les hooks utilisés par les extensions maison, et ne nécessitent donc pas de campagne de tests spécifique au-delà de la vérification habituelle post mise à jour.

### Exigences PHP à surveiller

Sur ce cycle, la compatibilité avec les versions récentes de PHP continue de progresser, avec des corrections régulières visant les avertissements de dépréciation apparus sur PHP 8.0 et 8.1. Un projet encore hébergé sur PHP 7.4 ne rencontrera pas de blocage immédiat, mais chaque version 6.x réduit un peu plus la marge de tolérance pour les hébergements restés sur des versions de PHP proches de leur fin de vie.

> Sur un parc de sites clients, la règle qui a le mieux fonctionné reste de grouper les montées de version WooCommerce par trimestre plutôt que de suivre chaque sortie mensuelle, sauf changement classé « impact fort » comme celui de l'API REST cette fois-ci.

## Pour aller plus loin

La prochaine version majeure, la 7.0, est déjà annoncée pour la fin d'année et devrait poursuivre ces deux chantiers de fond, stockage de commandes et blocs de tunnel de commande, sans rupture brutale annoncée à ce stade. La meilleure préparation pour cette suite consiste moins à anticiper des fonctionnalités encore incertaines qu'à s'assurer, dès maintenant, qu'aucune extension maison ne repose sur l'API REST legacy ni sur un accès direct aux tables de commandes en contournant les classes CRUD officielles de WooCommerce.