Le bouton « Valider la commande » ne répond plus au clic, sans message d’erreur visible, immédiatement après une mise à jour de Divi Builder sur une boutique WooCommerce dont le tunnel de commande avait été personnalisé graphiquement avec ce constructeur de pages. Le symptôme est net : aucune erreur affichée côté client, mais aucune requête de validation ne part non plus dans l’onglet réseau des outils de développement.
Symptôme précis observé
Le clic sur le bouton ne déclenche visiblement rien : pas de spinner de chargement, pas de requête wc-ajax=checkout dans l’onglet réseau du navigateur, et la console JavaScript affiche une erreur du type Uncaught TypeError: Cannot read properties of null, généralement pointée vers un script de Divi tentant d’attacher un gestionnaire d’événement à un élément que WooCommerce a lui-même déjà remplacé dynamiquement.
Diagnostic : deux scripts qui se disputent le même bouton
WooCommerce Blocks ou le tunnel de commande classique attache son propre gestionnaire de soumission au formulaire de commande via son script checkout.js natif. Quand Divi Builder a été utilisé pour reconstruire visuellement la mise en page de cette page (via son module de génération de contenu dynamique appliqué à la page commande), sa propre couche JavaScript peut réinitialiser ou dupliquer le bouton, cassant la liaison d’événement que WooCommerce avait posée au chargement initial de la page.
Ce type de conflit apparaît typiquement après une mise à jour de Divi qui modifie légèrement la structure DOM générée pour les modules de bouton, sans que l’éditeur ne soit conscient de l’existence du script WooCommerce sous-jacent.
Isoler le script fautif
// Dans la console du navigateur, sur la page de commande :
jQuery(document.body).off('click', '#place_order');
// Si le bouton se remet à fonctionner après cette commande,
// cela confirme qu'un gestionnaire tiers interceptait l'événement
// avant celui de WooCommerceCe test rapide en console confirme le diagnostic sans avoir à fouiller le code source de Divi. Une fois confirmé, la correction consiste à empêcher Divi de recharger sa propre couche de script sur cette page précise, plutôt que de désactiver Divi globalement sur tout le site.
Corriger sans perdre le style personnalisé
La solution la plus stable consiste à retirer la page de commande de la construction visuelle Divi (revenir au template WooCommerce standard pour cette page uniquement), tout en conservant le style CSS personnalisé appliqué séparément via une feuille de style enfant, plutôt que via des modules Divi actifs sur cette page précise :
/* Dans le thème enfant, style.css */
.woocommerce-checkout #place_order {
background-color: #1a1a1a;
border-radius: 4px;
padding: 14px 32px;
}Cette approche découple la présentation visuelle (gérable en CSS pur) du comportement fonctionnel du bouton (qui doit rester géré exclusivement par le script natif WooCommerce), ce qui évite ce type de conflit à chaque future mise à jour de Divi.
Verrouiller les mises à jour futures
- Tester systématiquement le tunnel de commande complet, jusqu’au paiement, sur un environnement de recette avant toute mise à jour de Divi en production
- Éviter d’utiliser un constructeur de pages visuel sur les pages fonctionnelles critiques (panier, commande), en réservant ces outils aux pages de contenu éditorial
- Documenter dans le projet la raison de cette exclusion, pour qu’une future intervention ne réintroduise pas Divi sur ces pages par méconnaissance
Un contrôle automatisé pour détecter la récidive tôt
Un test de bout en bout, exécuté automatiquement après chaque déploiement (via un outil comme Playwright ou Cypress), qui simule un ajout au panier suivi d’un clic sur le bouton de validation jusqu’à l’arrivée sur la page de remerciement, détecterait ce type de régression en quelques minutes plutôt qu’au moment où un client se plaint de ne pas pouvoir finaliser sa commande. Ce test reste léger à écrire une fois pour toutes et couvre un risque bien réel : n’importe quelle mise à jour de thème, d’extension ou même de WordPress lui-même peut réintroduire un conflit similaire sans lien direct avec Divi.
En résumé
Un bouton de validation de commande qui cesse de répondre après une mise à jour Divi révèle presque toujours un conflit de gestionnaire d’événement JavaScript entre le constructeur de pages et le script natif WooCommerce. Séparer clairement le style (CSS) du comportement (script natif), en excluant les constructeurs visuels des pages fonctionnelles critiques, prévient durablement ce type d’incident.
