Depuis novembre 2023, une boutique WooCommerce neuve démarre avec les blocs Panier et Validation de commande. Près de trois ans plus tard, la plupart des boutiques existantes tournent pourtant toujours sur l’ancienne page de commande, construite avec des codes courts. WooCommerce l’a reconnu lui-même au printemps 2025 : l’adoption reste plus faible que prévu.

Ce retard a des raisons solides. Les blocs reposent sur une autre architecture, une partie des personnalisations en PHP n’y passe pas, et certains plugins de paiement ou de champs ne suivent pas. Migrer sans préparation, c’est risquer une page de commande sans moyen de paiement, le pire écran possible pour une boutique.

Ce guide explique ce qui a changé avec WooCommerce 8.3, comment savoir ce que votre boutique utilise, le rôle de la Store API, l’audit des plugins, les champs personnalisés, le transfert des personnalisations, la migration pas à pas, les réglages des blocs et le retour en arrière. Les informations correspondent à WooCommerce 11.1.2, version en cours en octobre 2026, avec la version 11.2 attendue la semaine du 6 octobre. Pour le travail sur la conversion elle-même, notre guide pour optimiser la page de commande WooCommerce prend le relais.

Ce que WooCommerce 8.3 a changé, et ce qu’il n’a pas changé

Les nouvelles boutiques : les blocs par défaut

WooCommerce 8.3 est sorti le 16 novembre 2023, après un report de deux jours. Depuis, une nouvelle installation crée ses pages panier et commande avec les blocs, et, avec un thème de blocs, un modèle de confirmation de commande en blocs. Les blocs font partie du cœur de WooCommerce : le plugin séparé WooCommerce Blocks a été fermé définitivement sur wordpress.org en février 2024, et il n’y a rien à installer.

Les boutiques existantes : rien ne bouge tout seul

Une boutique mise à jour vers 8.3 ou une version ultérieure garde sa page de commande. WooCommerce l’a dit dès l’annonce, et l’a confirmé depuis : les codes courts restent pris en charge pour les boutiques existantes. La documentation recommande les blocs, tout en reconnaissant que la version en codes courts est parfois plus compatible avec les plugins.

Aucune date de fin n’a été annoncée pour la commande classique, qui reçoit encore des correctifs dans les versions 11.x. Les nouveautés arrivent toutefois d’abord du côté des blocs, et certaines n’existent que là.

Codes courts et blocs : deux architectures

La commande classique repose sur des modèles PHP et sur des crochets, ces points d’accroche où les plugins ajoutent du code. Les blocs reposent sur une interface React qui dialogue avec la Store API, une interface de programmation de WooCommerce. Les blocs intérieurs du cœur sont verrouillés : un marchand peut réordonner certaines sections, mais pas les supprimer, à l’exception du formulaire de code promo.

La page Mon compte n’a pas d’équivalent en blocs. Elle reste un code court, quelle que soit la page de commande choisie.

Savoir ce que votre boutique utilise aujourd’hui

Les pages assignées et leur contenu

Les pages panier et commande sont désignées dans WooCommerce, Réglages, Avancé, dans la rubrique « Installation des pages ». Ouvrez chacune d’elles dans l’éditeur. Un code court

ou

☀☾

Panier vide

Votre panier est vide pour l'instant.

Votre panier est vide. Parcourez le catalogue, ajoutez un article, puis revenez ici pour finaliser votre commande.

Parcourir le catalogue Mon compte

• Téléchargement immédiat après chaque commande payée.
• Clés de licence livrées avec les produits qui en utilisent.

signale la version classique. Un bloc Panier ou Validation de commande signale la version en blocs.

En ligne de commande, deux commandes WP-CLI standard suffisent : la première donne l’identifiant de la page de commande, la seconde affiche son contenu, en remplaçant 12 par l’identifiant obtenu.

wp option get woocommerce_checkout_page_id
wp post get 12 --field=post_content

Le cas des thèmes de blocs

Avec un thème de blocs, le bloc peut vivre dans un modèle de l’éditeur de site, « Page : validation de la commande » ou « Page : panier », plutôt que dans la page elle-même. WooCommerce regarde d’abord ces modèles. Notre guide du Full Site Editing et de theme.json explique comment ces modèles fonctionnent.

Le rapport d’état, dans WooCommerce, État, signale aussi une page qui ne contient ni le code court ni le bloc attendu. Après un retour en arrière, la page contient un bloc « Code court classique », qui enveloppe l’ancien code court : il compte comme une commande classique.

La Store API, le moteur sous les blocs

Une interface publique par conception

Les blocs Panier et Validation de commande ne parlent pas directement à PHP. Ils interrogent la Store API, une interface REST publique, sans authentification, qui expose le panier, la commande, les produits et quelques autres ressources. Sa documentation précise qu’elle ne donne accès à aucune donnée sensible de la boutique ni aux informations des autres clients.

Les requêtes d’écriture exigent un jeton de sécurité, transmis dans un en-tête, ou un jeton de panier pour les vitrines découplées. Une limitation de débit existe, désactivée par défaut. Depuis WooCommerce 9.6, l’option « Limitation du débit Checkout », dans les fonctionnalités avancées, limite les tentatives de commande à trois par minute, une protection utile contre les tests de cartes volées.

Pourquoi vos règles classiques ne la protègent pas

La Store API applique ses propres règles. Une règle métier écrite pour le panier classique ne la concerne pas. L’exemple est donné par WooCommerce lui-même : le filtre woocommerce_update_cart_validation, utilisé pour limiter des quantités, ne s’applique qu’au panier en code court. Le bloc Panier et tout client de la Store API le contournent.

WooCommerce 11.2 ajoute un filtre équivalent côté Store API, woocommerce_store_api_cart_item_quantity_validation, qui renvoie une erreur au lieu d’afficher un avis. Même après la mise à jour, une limite écrite à l’ancienne ne protège que le panier en code court : il faut ajouter un rappel sur le nouveau filtre, qui renvoie une erreur, et contrôler le premier ajout au panier avec woocommerce_store_api_validate_add_to_cart.

Étendre la Store API

Un plugin qui doit transmettre ses propres données au panier ou à la commande ne passe plus par les crochets d’affichage. Il étend le schéma de la Store API, avec la fonction woocommerce_store_api_register_endpoint_data(), et peut déclencher une mise à jour côté serveur depuis le navigateur grâce à un rappel enregistré par woocommerce_store_api_register_update_callback().

Cette interface gagne aussi en rapidité. Depuis WooCommerce 11.1, les types de blocs ne sont plus enregistrés lors des requêtes adressées à la Store API ou à l’API REST, ce qui les rend, selon WooCommerce, de 30 à 42 % plus rapides. Un filtre permet de revenir à l’ancien comportement si un plugin en dépend.

Le cas réel : quand la Store API montrait les commandes des invités

La Store API fait tourner les blocs, mais elle répond aussi sur chaque boutique WooCommerce, comme une porte d’entrée toujours ouverte. L’épisode de décembre 2025 l’a rappelé de façon très concrète. Il est documenté par WooCommerce, par le laboratoire de sécurité de GitHub, par WPScan et par les forums de wordpress.org.

La faille

La Store API comporte une route qui renvoie une commande à partir de son numéro. Sa documentation promet qu’elle ne permet pas de consulter les commandes des autres clients. Or, pour un utilisateur connecté, la vérification sautait le contrôle de la clé de commande et de l’adresse électronique de facturation.

En parallèle, le contrôle des droits de WooCommerce lui-même accordait à tout utilisateur connecté le droit de payer une commande, dès lors qu’elle n’était rattachée à aucun compte, ce qui est le cas de toutes les commandes passées en invité. Résultat : n’importe quel client connecté pouvait lire n’importe quelle commande d’invité en devinant son numéro, et les numéros de commande se devinent facilement.

Les données exposées comprenaient noms, adresses électroniques, numéros de téléphone, adresses de livraison et de facturation, type de moyen de paiement et articles achetés. Aucune donnée de carte bancaire n’était concernée. La faille touchait WooCommerce 8.1 à 10.4.2, soit environ deux ans de versions.

Quatre jours, toutes les versions depuis 8.1

La découverte est venue d’un agent d’intelligence artificielle développé par le GitHub Security Lab, que les chercheurs Man Yue Mo et Peter Stöckli avaient lancé sur le code de WooCommerce, premier logiciel de boutique en ligne de leur liste. L’agent a rapidement trouvé le moyen, pour un client connecté, de voir toutes les commandes des invités. Le signalement est parvenu à WooCommerce le 18 décembre 2025, par le programme de primes aux bogues d’Automattic.

Le 22 décembre, WooCommerce publiait des correctifs pour chaque branche concernée, de 8.1 à 10.4. L’équipe a travaillé avec l’équipe des plugins de wordpress.org pour mettre à jour automatiquement les sites touchés, et les boutiques hébergées par Automattic ont été corrigées d’office. WooCommerce qualifiait la faille de critique, et indiquait n’avoir constaté aucune exploitation en dehors de ses propres tests. Les bases de GitHub et de WPScan lui attribuent une note de 6,5 sur 10, soit une gravité moyenne.

Le débat sur la mise à jour forcée

Le jour même, sur le forum de wordpress.org, un administrateur de plusieurs sites, qui interdisait toute mise à jour automatique de ses plugins, demande pourquoi WooCommerce s’est mis à jour sur tous ses sites. Nadir Seghir, ingénieur de WooCommerce, explique que WooCommerce a demandé une mise à jour de sécurité forcée, ce qui n’arrive presque jamais en dehors d’un risque de sécurité.

Samuel Wood, administrateur de wordpress.org, précise que WordPress installe par défaut ces mises à jour de sécurité, sauf si les mises à jour automatiques sont coupées par des constantes dans wp-config.php. Quatre jours plus tard, un autre utilisateur, qui gère la boutique d’un client, regrette une mise à jour imposée juste avant Noël, sans préavis.

Le 6 mars 2026, le laboratoire de GitHub a publié son avis détaillé, et le blog de GitHub a expliqué que le même agent avait ensuite trouvé des failles du même type dans d’autres plateformes de commerce, dont Spree. Notre article sur les vulnérabilités WordPress en chiffres replace ce genre d’épisode dans son contexte.

Ce que cela change pour une migration

La leçon la plus utile est contre-intuitive. Aucune source ne limite la faille aux boutiques qui utilisaient le bloc Validation de commande : la démonstration appelait directement la Store API. Revenir aux codes courts ne coupe donc pas la Store API, qui fait partie du cœur de WooCommerce et répond sur chaque boutique.

La combinaison qui servait de condition, commande en invité et inscription libre des clients, est courante. Migration ou pas, la vraie protection reste de tenir WooCommerce à jour, et de tester ses règles métier contre la Store API, pas seulement contre la page de commande.

Auditer vos plugins avant de basculer

Les moyens de paiement

Un moyen de paiement doit s’enregistrer côté navigateur et côté serveur pour apparaître dans le bloc Validation de commande. Sans cette intégration, il disparaît tout simplement. Si aucun moyen compatible n’est actif, le client voit un message indiquant qu’aucun moyen de paiement n’est disponible.

Les grandes passerelles, WooPayments, Stripe, PayPal Payments, Square, Mollie ou Klarna, gèrent les blocs. La fiche de PayPal Payments sur wordpress.org qualifie encore cette prise en charge d’expérimentale, alors que sa page sur la place de marché la déclare compatible : testez-la avec soin. Notre comparatif des meilleures passerelles de paiement WooCommerce détaille chacune d’elles.

L’avertissement des plugins incompatibles

Dans l’éditeur, quand un plugin actif ne prend pas en charge le bloc, un avertissement apparaît dans la barre latérale, avec un bouton qui rebascule la page vers la commande classique en un clic, et une annulation possible. Depuis WooCommerce 10.7, un avertissement s’affiche aussi sur la page publique, aux administrateurs et aux gestionnaires de boutique.

Attention : seuls les plugins qui portent l’en-tête « WC tested up to » et se déclarent explicitement incompatibles déclenchent l’avertissement. Un plugin muet peut casser la commande sans aucun avertissement. Les moyens de paiement sans intégration sont signalés dans tous les cas.

Éditeurs de champs, constructeurs de pages et caisses de remplacement

Les éditeurs de champs sont un obstacle fréquent. Checkout Field Editor, de ThemeHigh, gère les deux commandes, mais avec des configurations séparées : les champs créés pour la commande classique ne fonctionnent pas dans le bloc, et inversement. Flexible Checkout Fields, de WP Desk, demande un produit distinct pour les blocs.

Les constructeurs de pages ajoutent leur propre couche. Elementor indiquait en 2024 que les blocs Panier et Validation de commande étaient incompatibles avec son éditeur, et recommandait ses propres widgets. Les plugins qui remplacent entièrement la page de commande, comme CheckoutWC, Fluid Checkout ou FunnelKit, rendent la question des blocs largement sans objet.

Abonnements et obligations légales

Les plugins qui touchent au cœur du parcours méritent un test dédié. WooCommerce Subscriptions se déclare compatible avec les blocs Panier et Validation de commande. Germanized, très utilisé pour les obligations légales des boutiques allemandes, prend en charge les deux commandes, et son journal des modifications montre des correctifs réguliers du côté des blocs.

Pour ces plugins, la compatibilité déclarée ne dispense pas d’un essai complet : un renouvellement d’abonnement, une case de consentement obligatoire ou une mention légale manquante ne se voient qu’en passant une vraie commande sur la copie de recette.

Les champs personnalisés : l’API des champs additionnels

Trois emplacements, quelques types

Dans le bloc Validation de commande, on n’ajoute plus de champs en modifiant le tableau des champs en PHP. WooCommerce fournit une API dédiée, introduite en version 8.5 et stable depuis la 8.9, en mai 2024. Un champ s’affiche dans un seul de trois emplacements : les coordonnées, l’adresse ou les informations de commande.

Le choix de l’emplacement décide du stockage. Un champ d’adresse est demandé deux fois, pour la facturation et la livraison. Un champ de coordonnées est enregistré dans le compte du client et dans la commande. Un champ de commande n’est enregistré que dans la commande.

add_action( 'woocommerce_init', function () {
	woocommerce_register_additional_checkout_field(
		array(
			'id'       => 'mon-plugin/numero-tva',
			'label'    => 'Numéro de TVA',
			'location' => 'contact',
			'type'     => 'text',
			'required' => false,
		)
	);
} );

En version 11.1.2, trois types existent : texte, liste déroulante et case à cocher. Le type date arrive avec WooCommerce 11.2. L’enregistrement doit se faire sur l’action woocommerce_init ou plus tard, et la version 11.0 avertit en cas d’enregistrement trop précoce.

Validation et champs conditionnels

Chaque champ accepte une fonction de nettoyage et une fonction de validation. Depuis WooCommerce 9.9, les propriétés obligatoire, masqué et validation peuvent dépendre d’autres valeurs, décrites en JSON Schema et évaluées dans le navigateur comme sur le serveur. Un champ de numéro de TVA peut ainsi n’apparaître que pour une adresse professionnelle.

Transférer les personnalisations en PHP

Les crochets qui survivent, et les autres

WooCommerce publie une table de correspondance des crochets. Ceux qui touchent au calcul, comme les frais du panier, le recalcul des totaux, les tarifs de livraison ou les formats d’adresse par pays, fonctionnent avec les blocs. Ceux qui affichent du contenu à un endroit précis de la page classique, avant le formulaire ou après les notes de commande, n’existent pas dans le bloc.

Le crochet woocommerce_checkout_order_processed ne se déclenche pas pour les commandes passées par la Store API : il faut utiliser woocommerce_store_api_checkout_order_processed. La modification des champs du cœur par le filtre woocommerce_checkout_fields n’est pas prise en charge du tout.

Emplacements, filtres JavaScript et blocs intérieurs

Pour afficher du contenu, le bloc propose des emplacements prévus à cet effet, tous encore marqués expérimentaux. Pour modifier un libellé, des filtres JavaScript existent, comme celui du bouton de validation de commande. Pour le reste, un plugin peut enregistrer son propre bloc intérieur, ou filtrer le rendu d’un bloc côté serveur.

La documentation des crochets affirme qu’on ne peut pas changer le texte du bouton de commande par le code : c’est inexact, le filtre JavaScript placeOrderButtonLabel le permet. Le texte se modifie aussi directement dans l’éditeur.

Migrer pas à pas

Préparer sur une copie

Travaillez sur une copie de recette, avec une sauvegarde récente de la production. Listez vos moyens de paiement, vos plugins liés à la commande et votre code sur mesure, et vérifiez chacun d’eux sur la place de marché ou dans sa documentation.

Remplacer le code court

Ouvrez la page de commande, remplacez le code court par le bloc Validation de commande, ou transformez le bloc qui enveloppe le code court en blocs. Faites de même pour le Panier : les deux pages doivent passer ensemble. Avec un thème de blocs, travaillez dans le modèle correspondant de l’éditeur de site.

L’outil « Créer les pages WooCommerce par défaut », dans les outils de l’écran État, ne convertit pas une page existante : il crée seulement les pages absentes. Supprimer les anciennes pages pour les faire recréer change leurs identifiants et leurs adresses, avec des conséquences sur les menus et les redirections.

Tester ce qui compte

Passez une commande complète avec chaque moyen de paiement, y compris les paiements express. Vérifiez les champs additionnels dans la commande, dans l’administration et dans les courriels. Contrôlez l’événement d’achat de vos outils de mesure, puis surveillez le taux de conversion et les commandes en échec pendant les semaines qui suivent la bascule.

Personnaliser avec les réglages des blocs

Des réglages répartis dans les blocs intérieurs

Le bloc Validation de commande lui-même n’a presque aucun réglage. Tout se trouve dans ses blocs intérieurs : les étapes numérotées du formulaire, l’affichage de la société, du complément d’adresse et du téléphone, masqués, facultatifs ou obligatoires, le style des boutons de paiement express, les icônes et coûts de livraison, la case obligatoire des conditions générales, ou le lien de retour au panier.

Le formulaire de code promo est le seul bloc intérieur qu’on peut retirer du récapitulatif. Le texte du bouton de commande se modifie directement dans l’éditeur. Avec un thème de blocs, le modèle de commande affiche volontairement un en-tête simplifié, avec le logo et le titre.

Ce que change la version 11.2

WooCommerce 11.2 modifie la mise en page : la colonne latérale passe à 360 pixels fixes au lieu de 35 %, et le seuil des deux colonnes passe de 700 à 920 pixels de largeur du conteneur. Un CSS sur mesure calé sur les anciennes valeurs risque de se décaler. Vérifiez votre page de commande sur une copie après la mise à jour.

Revenir aux codes courts

Transformer le bloc

Le retour en arrière officiel est simple. Ouvrez la page de commande, ou son modèle avec un thème de blocs, sélectionnez le bloc Validation de commande dans la vue en liste, utilisez la transformation de la barre d’outils et choisissez « Code court classique », puis enregistrez. Faites de même pour le Panier : WooCommerce recommande de revenir sur les deux pages.

Quand un plugin incompatible est détecté, le bouton de la barre latérale fait la même chose en un clic, avec une annulation possible. Les révisions de WordPress gardent de toute façon l’ancien contenu de la page.

Ce qu’un retour en arrière ne défait pas

Revenir aux codes courts ne coupe pas la Store API, comme l’a montré la faille de décembre 2025. Les règles métier ajoutées pour les blocs, côté Store API, restent utiles même sur une commande classique. Et les champs créés avec l’API des champs additionnels n’apparaissent pas dans la commande classique.

Faut-il migrer maintenant ?

Ce que les blocs apportent en propre

Certaines fonctions n’existent qu’avec les blocs : le retrait en magasin dans sa version en blocs, la création de compte différée, qui exige aussi un thème de blocs, ou l’option expérimentale de mise de côté dans le panier. D’autres nouveautés, comme la saisie semi-automatique des adresses, sont arrivées dans les deux commandes.

Ce que disent vraiment les chiffres

WooCommerce a annoncé des gains de conversion d’environ 20 % en 2021, puis de quelques points en 2024, et l’un de ses responsables produit, James Kemp, a évoqué 27 % sur X en février 2026, sans méthode publiée. En avril 2026, l’éditeur de plugins Studio Wombat relevait que seules 12 % des quelque 7 200 boutiques de sa clientèle dont il avait pu analyser la page panier utilisaient le bloc Panier. Ces chiffres restent des affirmations de vendeurs : seule une mesure sur votre boutique tranche.

Pour une boutique neuve, les blocs sont le choix naturel. Pour une boutique très personnalisée, la migration se décide après l’audit, plugin par plugin. Si votre commande passe par un constructeur de pages, notre comparatif Gutenberg contre les constructeurs de pages aide à trancher la question de fond.

Tableau récapitulatif

Sujet	Commande en codes courts	Commande en blocs	À vérifier
Architecture	Modèles PHP et crochets	React et Store API	Code sur mesure
Moyens de paiement	Tous	Seulement ceux intégrés	Chaque passerelle en recette
Champs ajoutés	Filtres PHP, plugins	API des champs additionnels	Courriels et administration
Fonctions récentes	Correctifs, quelques nouveautés	Nouveautés en premier	Besoin réel de la boutique
Store API	Active	Active	Mises à jour, règles métier
Retour en arrière	Sans objet	Transformation en un clic	Les deux pages ensemble

Questions fréquentes

WooCommerce va-t-il supprimer la commande en codes courts ?

Aucune date n’a été annoncée. WooCommerce a promis à plusieurs reprises de continuer à la prendre en charge pour les boutiques existantes, et la corrige encore dans les versions 11.x.

Faut-il installer le plugin WooCommerce Blocks ?

Non. Ce plugin a été fermé définitivement en février 2024. Les blocs Panier et Validation de commande font partie de WooCommerce.

Pourquoi mon moyen de paiement n’apparaît-il pas dans le bloc Validation de commande ?

Parce que son plugin ne fournit pas l’intégration nécessaire aux blocs. Mettez-le à jour, vérifiez sa compatibilité sur la place de marché, ou revenez à la commande classique en attendant.

Peut-on ajouter un champ de numéro de TVA sans plugin ?

Oui, avec quelques lignes de code et l’API des champs additionnels, dans l’emplacement des coordonnées ou de l’adresse. Un plugin d’édition de champs reste plus simple si vous ne voulez pas écrire de code.

La commande en blocs convertit-elle mieux ?

WooCommerce l’affirme, avec des chiffres qui ont varié et sans méthode publiée. Mesurez sur votre propre boutique, avant et après la bascule, plutôt que de vous fier à une moyenne.

Conclusion

Les blocs Panier et Validation de commande sont l’avenir de WooCommerce, et les nouvelles boutiques y sont déjà. Pour une boutique existante, la migration n’a rien d’automatique et c’est tant mieux : elle demande un audit des moyens de paiement, des plugins et du code sur mesure, une recette complète et un plan de retour.

Gardez aussi en tête la leçon de décembre 2025. La Store API répond sur chaque boutique, quelle que soit la page de commande. Tenir WooCommerce à jour et tester ses règles contre cette interface protège davantage que le choix entre codes courts et blocs.

Sources

• WordPress.org Plugins. WooCommerce
• WooCommerce Developer Blog (16 novembre 2023). WooCommerce 8.3.0 Released
• WooCommerce Developer Blog (14 novembre 2023). WooCommerce 8.3 delayed
• WooCommerce Developer Blog (18 août 2023). Cart and Checkout Blocks: Becoming the Default Experience
• WooCommerce Developer Blog (6 novembre 2023). FAQ: Cart and Checkout Blocks by Default
• WooCommerce Developer Blog (18 septembre 2023). Understanding the Architecture of Cart and Checkout Blocks
• WordPress.org Plugins. WooCommerce Blocks
• WooCommerce. Page Shortcodes
• WooCommerce. Customizing the Cart and Checkout Pages
• WooCommerce. Checkout block
• WooCommerce. Cart block
• WooCommerce Developer Docs. Store API
• WooCommerce Developer Docs. Rate limiting
• WooCommerce Developer Blog, Shani Banerjee (24 septembre 2026). New Store API filter for validating cart item quantities in 11.2
• WooCommerce Developer Blog, Shani Banerjee (21 septembre 2026). WooCommerce 11.2.0 Pre-release notes
• WooCommerce Developer Blog, Beau Lebens (22 décembre 2025). Store API Vulnerability Patched in WooCommerce 8.1+: What You Need To Know
• GitHub Security Lab (6 mars 2026). GHSL-2025-129: WooCommerce Exposes Sensitive Order Information to any Logged-In Customer
• The GitHub Blog, Man Yue Mo et Peter Stöckli (6 mars 2026). How to scan for vulnerabilities with GitHub Security Lab’s open source AI-powered framework
• GitHub Advisory Database (22 décembre 2025). CVE-2025-15033
• WPScan (22 décembre 2025). WooCommerce, Subscriber/Customer+ Order Data Disclosure
• WordPress.org Forums (décembre 2025). The plugin was updated automatically. Why?
• WooCommerce Developer Docs. Payment method integration
• WooCommerce Developer Docs. Cart and Checkout blocks extensibility
• GitHub, WooCommerce. Pull request 62242, front-end incompatibility notice
• WordPress.org Plugins. WooCommerce PayPal Payments
• ThemeHigh. Classic vs Block Checkout
• WordPress.org Plugins. Flexible Checkout Fields for WooCommerce
• Elementor Help Center. I receive an error message when using the WooCommerce block
• WordPress.org Plugins. CheckoutWC Lite
• WooCommerce Developer Docs. Additional checkout fields
• WooCommerce Developer Docs. Hook alternatives
• WooCommerce Developer Docs. Checkout and place order button filters
• WooCommerce. System Status Report, Tools
• WooCommerce. Customizing the Cart page
• WooCommerce Developer Blog (17 décembre 2024). WooCommerce 9.5: delayed account creation and cross-selling
• WooCommerce Developer Blog, Brian Coords (28 avril 2025). Call for Participants: Help us understand checkout block adoption barriers
• WooCommerce Developer Blog (31 août 2021). Peek into the WooCommerce Blocks roadmap
• WooCommerce Developer Blog (23 juillet 2024). WooCommerce in 2024 and beyond: roadmap update
• Business Bloomer, Rodolfo Melogli (24 février 2026). My Honest Take on WooCommerce Checkout Block Adoption
• Studio Wombat, Maarten Belmans (avril 2026). WooCommerce Data Insights, 2026 Edition
• WooCommerce Developer Docs. Extending the Store API
• WooCommerce Developer Blog (3 septembre 2026). WooCommerce 11.1 release notes
• WooCommerce Marketplace. WooCommerce Subscriptions
• WordPress.org Plugins. Germanized for WooCommerce
• WordPress.org Plugins. WooPayments
• WordPress.org Plugins. WooCommerce Stripe Payment Gateway
• WooCommerce Marketplace. WooCommerce PayPal Payments
• GitHub, WooCommerce. checkout-express-payment-block, block.json
• WooCommerce. Customizing the Checkout page
• WooCommerce Developer Docs. Available Slots
• WooCommerce Developer Docs. Add data to Store API
• WooCommerce Developer Blog (22 octobre 2025). WooCommerce 10.3

---

LaFactory conçoit, développe et maintient des sites WordPress et WooCommerce, et développe ses propres plugins. Parlons de votre projet WordPress.