Rien n’est ajouté tant que le client ne le demande pas.

L’article répond deux fois à cette question, puis se contredit une fois ; voici donc les trois passages, dans l’ordre où ils apparaissent. Frontend Result : « Le cadeau ne sera pas ajouté automatiquement. À la place, le client verra un bouton Claim Gift qui lui permet d’ajouter manuellement l’article gratuit à son panier. » La question de la FAQ « Puis-je ajouter le cadeau automatiquement au panier ? » : « Non. Le booster Cadeau offert ne prend actuellement en charge que la sélection manuelle du cadeau. Les clients doivent cliquer activement sur le bouton “Add Gift” pour inclure le cadeau dans leur panier une fois les conditions remplies. » La question de la FAQ « Que se passe-t-il si le client retire le produit qualifiant ? » : « Le booster réévaluera automatiquement les conditions. Si elles ne sont plus remplies, le cadeau sera retiré du panier s’il avait été ajouté automatiquement. » La troisième phrase présuppose un état que les deux premières nient. Ce qui est tranché dans les deux sens, c’est le retrait : Frontend Result indique de son côté que si le panier ne qualifie plus, le cadeau sera masqué ou retiré automatiquement — un cadeau qui cesse de qualifier s’en va donc, quelle que soit la manière dont il est arrivé. Ce qui n’est pas tranché, c’est l’existence même d’un chemin d’ajout automatique. Notre lecture — et c’est une lecture, pas un fait — est que la troisième phrase est un texte générique repris d’un booster qui, lui, ajoute automatiquement, dans un article qui appelle aussi cette offre un « combo », appelle le bloc un « bloc de recommandation » et appelle le cadeau un « Add-on » ; trois autres chaînes égarées, toutes visibles sur la même page. La démo de ce site n’ajoute donc jamais le cadeau d’elle-même, et ne le fera pas tant que 8theme n’aura pas dit le contraire. Testez-le sur une copie de préproduction avant d’en faire une règle de gestion. Un dernier point que ces mêmes passages laissent ouvert : le libellé du bouton. Frontend Result l’appelle Claim Gift, la FAQ l’appelle « Add Gift », et les trois captures de 8theme montrent Add gift to cart saisi dans le champ Offer CTA button text. C’est du texte libre sans valeur par défaut publiée — le nôtre affiche Recevoir le cadeau.

Le champ existe et il a quatre valeurs, mais les deux sources ne le nomment pas pareil : le texte l’appelle Discount Type, la capture admin l’étiquette Gift type. Ses options, citées : Percentage, par exemple 20% de remise ; Fixed, par exemple $5 de remise ; Free, où le prix est ramené à $0 ; et No discount, où le produit de l’offre sera affiché à son prix normal. Un champ Discount Value est décrit dans le texte — saisissez 15 pour 15% de remise, saisissez 10 pour $10 de remise, sans objet si Free ou No discount est sélectionné — et il n’apparaît nulle part sur l’unique capture de ce panneau, où Gift type est réglé sur Free. Savoir si le champ est masqué ou simplement ignoré sous Free reste donc sans réponse. Deux autres silences méritent d’être nommés. Rien de publié ne dit si un cadeau remisé mais non gratuit s’affiche encore avec le mot FREE et l’habillage cadeau côté boutique ; cette page ne passe donc cette ligne en vert que lorsque le prix est réellement nul : une ligne qui annonce une offre reçoit la pastille, une ligne à son prix normal, non. Et rien ne dit comment un cadeau en pourcentage ou en montant fixe interagit avec un coupon, une règle de taxe ou un calcul de livraison.

Display Location est un sélecteur unique à onze valeurs, dont l’une est Use a shortcode : quatre se lisent comme des positions de la page panier — Top of the Cart page, Before Cart items table, After Cart items table, After Cart items within the table — et six comme des positions de la page de commande — Before Payment Gateways, Before Place Order Button, After Place Order Button, Bottom of the Checkout Page, Before Billing section, After Order notes. Soit dix positions et un shortcode. Mini cart location est un second sélecteur à sept valeurs, dont Do not display est un état désactivé, ce qui laisse six positions : Top of the Mini Cart, Before Cart items, After Cart items within the list, Before buttons, After buttons, Bottom of the Mini Cart. L’article ne donne le nombre d’aucune des deux listes, et il ne nomme de défaut pour aucune : l’unique capture de ce panneau montre Before Cart items table et Do not display, qui sont des valeurs affichées et non des défauts déclarés. Leurs deux conseils : placer le booster après les articles du panier ou avant la section de paiement peut augmenter la visibilité et l’engagement juste avant la conversion, et placer l’offre de cadeau près des boutons du mini-panier est efficace pour des relances de dernière minute. Il existe aussi une route Elementor, et son propre panneau porte la restriction par écrit : ce booster ne peut être utilisé que sur les modèles de page Panier ou Commande. Ce que personne ne publie, c’est si les onze valeurs sont proposées sur les deux types de page ou filtrées selon la page.

Oui dans les deux cas, et l’article est inhabituellement direct là-dessus. Interrogé sur la baisse de stock, il répond : « Oui. L’article offert est un vrai produit WooCommerce et il est déduit du stock comme n’importe quel autre article lors du paiement. » Frontend Result ajoute qu’une fois ajouté, le cadeau apparaît comme un produit ordinaire dans le panier au prix de $0, et qu’il sera aussi inclus dans le récapitulatif de commande au paiement. Chaque rendu de la ligne réclamée — le leur comme celui de cette page — porte son propre lien Supprimer, comme toute autre ligne du panier. Une chose siège dans le panneau admin sans une seule phrase pour l’accompagner : une case cochée qui lit « Allow customers to remove Add-ons from the cart? ». Elle n’est pas documentée dans le texte, et elle dit toujours Add-ons, qui est le nom d’un autre booster. Ce qu’elle commande ici relève d’une supposition que nous ne ferons pas.

Deux champs, tous deux documentés. Total Usage Limit fixe le nombre maximal de fois que cette offre peut être utilisée, tous clients confondus, et le conseil de l’article la dit utile pour des campagnes à durée limitée ou des offres à stock contrôlé. Usage Limit Per Customer définit combien de fois un client donné peut réclamer l’offre, et son conseil dit qu’elle aide à prévenir les abus de la promotion en limitant les usages répétés par utilisateur. Les deux champs portent le texte indicatif Unlimited usage sur la capture, donc l’absence de limite est l’état livré. Lisez tout de même attentivement la réponse de la FAQ à ce sujet, à cause d’un mot : elle dit que le réglage garantit que chaque utilisateur connecté ne peut réclamer le cadeau qu’une seule fois. Rien de publié ne dit comment une limite par client s’applique à une commande passée en visiteur, ni ce qui se passe si une limite est atteinte alors qu’un client est en pleine session avec l’offre déjà à l’écran.

Un cadeau par booster : interrogé sur la possibilité d’appliquer plusieurs cadeaux à la fois, l’article répond qu’un seul cadeau par booster est possible et que, pour en proposer plusieurs, vous pouvez créer des boosters séparés avec leurs propres règles. Il confirme aussi la route multi-campagnes pour le ciblage : créez plusieurs campagnes Cadeau offert et donnez à chacune ses propres filtres de produit, de catégorie ou de condition de panier. Ce qui n’est pas publié, c’est ce qui se passe quand deux de ces campagnes qualifient sur le même panier. Un champ Priority existe — il figure sur la capture Optional Settings avec la valeur 10 — et aucune phrase, nulle part, ne dit ce qu’il classe ni quel sens l’emporte. Notez aussi que ce booster n’a pas de panneau Apply to à lui, si bien que le déclencheur derrière leurs propres exemples, dépenser plus de $75 ou acheter 3 sacs ou plus, n’est atteignable que par Conditions : Order total, Order items quantity, Products in Order. L’article ne le dit jamais en toutes lettres.