Chapitre 10.4 — Développer une extension WooCommerce

⏱️ TL;DR — Une extension WooCommerce est un plugin WordPress (Partie 7) qui dépend de WooCommerce : elle doit vérifier que Woo est actif, déclarer sa compatibilité (notamment HPOS et le checkout blocs), utiliser les objets/data stores (pas le SQL direct, ch. 10.1), et se brancher sur les hooks Woo (ch. 10.2). C’est le socle des missions e-commerce sur mesure (et un marché premium via la marketplace WooCommerce, Partie 13).

🎯 Objectifs

• Structurer une extension qui dépend de WooCommerce.
• Vérifier la présence de Woo et gérer l’absence proprement.
• Déclarer la compatibilité HPOS et checkout blocs.
• Suivre les bonnes pratiques (objets, hooks, sécurité, i18n).

1. Un plugin qui dépend de WooCommerce

Une extension est un plugin classique (en-tête, activation, structure — Partie 7) avec une dépendance déclarée :

<?php
/**
 * Plugin Name: WPR Woo Extras
 * Description: Extension d'exemple pour WooCommerce.
 * Requires Plugins: woocommerce
 * Requires PHP: 8.1
 * Text Domain: wpr-woo
 */
if ( ! defined( 'ABSPATH' ) ) { exit; }

• Requires Plugins: woocommerce (en-tête, WP 6.5+) déclare la dépendance : WordPress empêche l’activation si Woo est absent.
• On vérifie aussi à l’exécution (voir §2), pour les environnements plus anciens.

2. Vérifier la présence de WooCommerce

add_action( 'plugins_loaded', function () {
    if ( ! class_exists( 'WooCommerce' ) ) {
        add_action( 'admin_notices', function () {
            echo '<div class="notice notice-error"><p>'
               . esc_html__( 'WPR Woo Extras nécessite WooCommerce actif.', 'wpr-woo' )
               . '</p></div>';
        } );
        return; // ne rien brancher d'autre
    }
    // … initialiser l'extension (hooks Woo) …
} );

⚠️ Piège n°1 — supposer Woo présent. Appeler wc_get_product() ou WC() sans Woo actif provoque une erreur fatale (fonction inexistante). Toujours garder l’init derrière un class_exists('WooCommerce') et échouer proprement (notice admin), pas par un écran blanc.

3. Déclarer la compatibilité HPOS (obligatoire)

Depuis HPOS (ch. 10.1), une extension doit déclarer qu’elle est compatible avec le stockage des commandes en tables, sinon WooCommerce l’affiche comme incompatible (et peut restreindre HPOS) :

add_action( 'before_woocommerce_init', function () {
    if ( class_exists( \Automattic\WooCommerce\Utilities\FeaturesUtil::class ) ) {
        \Automattic\WooCommerce\Utilities\FeaturesUtil::declare_compatibility(
            'custom_order_tables', __FILE__, true // HPOS compatible
        );
        \Automattic\WooCommerce\Utilities\FeaturesUtil::declare_compatibility(
            'cart_checkout_blocks', __FILE__, true // checkout blocs compatible
        );
    }
} );

⚠️ Piège n°2 — extension « HPOS-incompatible ». Si votre code lit les commandes via WP_Query( 'shop_order' ) ou get_post_meta sur une commande, il est incompatible HPOS — et sur une boutique HPOS, il casse (ne voit pas les commandes). Utilisez wc_get_orders() / WC_Order et déclarez la compat. C’est aujourd’hui un critère d’acceptation sur la marketplace WooCommerce.

4. Utiliser les objets et les hooks

Toute la logique passe par les objets (WC_Product, WC_Order, WC_Cart) et les hooks (ch. 10.2) :

// Exemple : appliquer une remise selon une règle métier
add_action( 'woocommerce_cart_calculate_fees', function ( $cart ) {
    if ( is_admin() && ! wp_doing_ajax() ) { return; }
    if ( $cart->get_subtotal() >= 100 ) {
        $cart->add_fee( __( 'Remise fidélité', 'wpr-woo' ), -10 );
    }
} );

• On lit le panier via l’objet $cart (fourni par le hook), on applique une fee (remise négative) — pas de calcul de total « à la main ».
• La garde is_admin() && ! wp_doing_ajax() évite d’exécuter le calcul hors contexte panier.

5. Bonnes pratiques d’extension

• Objets/data stores partout (jamais SQL direct sur les commandes/produits).
• Compat HPOS + checkout blocs déclarée.
• Hooks plutôt que surcharge de templates (ch. 10.2).
• Sécurité (Partie 7.7) : nonces sur les actions, sanitize/escape, capabilities.
• i18n (ch. 7.8) avec un text domain propre.
• Tester contre plusieurs versions de Woo/WP (Partie 11 : CI), Woo évoluant vite.
• Logger proprement (wc_get_logger()), utile pour le support.

💡 Pour un dev React — Développer pour WooCommerce, c’est développer un plugin qui étend un domaine métier riche via ses objets et ses événements (hooks). Les mêmes principes que vos intégrations : parler à l’API/aux services (jamais à la base directement), déclarer ses compatibilités (comme un peerDependencies), réagir aux événements du cycle de vie. HPOS = une migration de backend que votre code traverse sans dommage s’il parle aux objets. Le marché des extensions Woo (surtout côté React/checkout blocs) est lucratif et sous-pourvu.

✏️ Exercices

1. Pourquoi et comment vérifier la présence de WooCommerce avant d’initialiser une extension ?
2. Que doit déclarer une extension moderne, et que se passe-t-il sinon ?
3. Pour appliquer une remise conditionnelle au panier, quel hook et quelle méthode utilisez-vous ?

🧠 Quiz de révision

Chapitre suivant : Paiements & passerelles.