Octobre 2022 : WooCommerce 7.0 sort, et avec elle une série de changements qui, pris isolément, semblent mineurs, mais qui s’accumulent suffisamment pour justifier une revue complète d’un type de produit personnalisé développé en interne. C’est le cas d’une extension maison qui ajoute un type de produit « location de matériel » à un catalogue WooCommerce, avec sa propre classe héritée de WC_Product et son propre gabarit d’affichage en fiche produit.
Une montée de version majeure de WooCommerce ne casse presque jamais tout d’un coup ; elle déplace des priorités de hooks, ajoute des méthodes recommandées en remplacement d’anciennes, ou modifie des comportements par défaut suffisamment discrets pour passer inaperçus tant qu’aucun test de non-régression n’est exécuté sur la fiche produit personnalisée.
Vérifier l’héritage de la classe de produit
Le point de départ de toute extension de type de produit reste la classe WC_Product et son enregistrement via le filtre woocommerce_product_class. Cette mécanique n’a pas changé avec la version 7.0, ce qui rassure sur la stabilité de fond de l’API produit. En revanche, il vaut la peine de vérifier que la méthode get_type() renvoie toujours la valeur attendue après la mise à jour, certaines extensions tierces réagissant à ce type pour afficher des blocs d’information complémentaires en fiche produit.
add_filter( 'woocommerce_product_class', function ( $classname, $product_type ) {
if ( 'location-materiel' === $product_type ) {
$classname = 'WC_Product_Location_Materiel';
}
return $classname;
}, 10, 2 );
HPOS : anticiper sans se précipiter
WooCommerce 7.0 introduit une prévisualisation du stockage haute performance des commandes (High-Performance Order Storage, ou HPOS), qui remplacera à terme le stockage des commandes sous forme d’articles (wp_posts). Cette fonctionnalité est encore en version bêta à ce stade et ne concerne pas directement l’affichage d’un type de produit, mais tout code qui interroge directement la table wp_posts pour retrouver des commandes liées à ce produit personnalisé devrait déjà prévoir une couche d’abstraction, via wc_get_orders() plutôt que des requêtes SQL directes.
Priorités de hooks sur la fiche produit
Certains hooks d’affichage de la fiche produit ont vu leur ordre d’exécution ajusté légèrement dans les versions récentes de la branche 7. Un type de produit personnalisé qui accroche son propre calendrier de disponibilité (pour la location de matériel, par exemple) sur woocommerce_single_product_summary avec une priorité fixe devrait revérifier son positionnement visuel après la mise à jour : un bloc qui s’affichait avant le prix peut désormais apparaître après, si un autre composant a changé de priorité par défaut.
Cas concret : le calendrier de disponibilité
Sur l’extension « location de matériel » prise en exemple, le calendrier de disponibilité était accroché à la priorité 25 sur woocommerce_single_product_summary, juste après le prix natif (priorité 10) et avant le bouton d’ajout au panier (priorité 30). Après la montée de version, un nouveau bloc d’information sur les stocks introduit par le thème utilisé s’est glissé à la priorité 20, rompant l’ordre visuel prévu initialement. Le correctif a consisté à décaler explicitement la priorité du calendrier à 22.
Ce qu’il faut tester avant de valider la mise à jour
- Affichage complet de la fiche produit personnalisée, dans l’ordre attendu des blocs.
- Ajout au panier et calcul du prix pour le type de produit personnalisé.
- Toute requête directe à
wp_postsqui devrait être remplacée par les fonctions d’API officielles avant l’arrivée définitive de HPOS. - Compatibilité des extensions tierces qui interagissent avec ce type de produit (comparateur de prix, export vers un flux Google Shopping, etc.).
Une montée de version majeure de WooCommerce se teste toujours fiche produit par fiche produit, pas type de produit standard par type de produit standard : c’est la fiche personnalisée qui révèle les décalages, jamais le produit simple générique.
Verdict
WooCommerce 7.0 ne remet pas en cause l’architecture d’un type de produit personnalisé correctement construit sur WC_Product, mais elle rappelle qu’aucune montée de version majeure ne doit être appliquée en production sans avoir rejoué, sur un environnement de recette, le parcours complet d’achat pour chaque type de produit maison de la boutique.
